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ABSTRACT 


A system is proposed which will support computer gaming 
in real-time. This system will, when combined with the user's 
Control Program, monitor all of the functions necessary to 
provide real-time man/machine interaction with the game. The 
formal definition of a programming language (RTGS Control 
Program Commang Language) is given; this language, supplemen- 
ted by Fortran IV and IBM 0S/360 Assembler Language is used 
for coding the user's Control Program. Plans for implementa- 
tion on an IBM System/360 Model 67 are discussed and a sample 


program is given. 
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FOREWORD 


The proposal made here is for a real-time system for 
gaming. The system encompasses a source language adaptable 
to gaming and a compiler and monitor system for generating 
and running games. The aim is to provide the capability for 
gaming in real-time with dynamic interaction between the 
players and the computing machinery. This is to be done 
without the requirement for tedious attention to the details 
of real-time programming or a special hybrid computer instal- 
lation. The system is designed to run on a general purpose 
digital computer with a tele-processing capability. 

The specific installation for which the pilot system 
was designed is the IBM 0S/360, Model 67 installed at the 
Naval Postgraduate School. The system has not, at this time, 
been fully implemented; however, the feasibility of such a 
system has been investigated by partial implementation. 

The thesis presents a formal definition of the system. 
It goes into some detail on the individual commands; however, 
it is not meant to serve as a users' manual for the system. 
Most of the details of generating and running the system were 
intentionally left out since they are mostly a function of 
the final implementation. 

The present intention of the author is to continue with 
the implementation and provide a full scale system. It is 
anticipated that when the system is available, a Technical 


Paper will be published with the details of the implementation. 


CHAPTER I 
INTRODUCTION 

In recent years, gaming and simulation techniques have 
emerged as powerful tools to aid in the solution of problems 
hitherto unsolvable by conventional techniques. Gaming and 
simulation techniques are used to model "real world" situa- 
tions in order to test the sensitivity of various parametric 
Changes. In this manner it is possible to try various 
courses of action and make observations as to which are 
best. 

Programming techniques for gaming vary markedly, being 
mostly a function of the type of computing machinery upon 
which the game will be run. At one end of the scale is the 
completely "self-contained" game, programmed to run on a 
general purpose digital computer with no human intervention 
during the play of the game. At the other end of the scale 
is the game programmed for hybrid computing systems or 
training devices which depend very heavily on "man-machine" 
interaction for their operation. These broad categories of 


programming techniques will be discussed separately. 


Self Contained Games 

Self contained games do not require any intervention 
while they are running. In this type gaming there are two 
basic programming techniques employed; time-step gaming and 


event-store gaming. 


Time-step game. The time-step game is, as its name 
implies, a game in which the play takes place in discrete 
frames of time. Each frame of time represents a cycle in 
the game. During each time cycle, the elements of the game 
are tested and decisions are made as to how they interact. 
The elements are then updated to represent their new posi- 
tions for going into the next cycle. The clock is advanced 
an amount equal to the cycle time and the game continues in 
the same manner until some pre-determined number of cycles 
have been processed or until some condition occurs. As the 
game proceeds, various parameters may be measured, statis- 
tics collected, tests conducted, etc.; the results are re- 
corded for outputting after the game is completed. One of 
the major drawbacks of this type of game is that it is 
essentially discrete in its representation of the "real- 
world" and the only way to make it appear continuous is to 
make the time cycle very short with respect to the factors 
which are being measured. If this is not done, the resolu- 
tion of the results may be unacceptable. For example, in 
a system where minutes are important it may be necessary 
to use the second as the basic time unit in order to get 
smooth results; however, each time-cycle usually involves 
a complete, or at least partial, updating of all of the 
force-units in the game as well as all other variable fac- 
tors, a large portion of which do not effect the outcome of 
the game within the current cycle. The result is that, in 


some games, much unnecessary computation and manipulation 


of data is done. Consider the scenario illustrated in Fia- 


ure l which represents a small segment of a theater-of- 
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Figure 1 


Ship A is searching north along track A using a radar 
set that detects according to some probabilistic range law. 
Ship B is proceeding west along track B and will eventually 
come into the radar envelope of ship A. It is desired that 
measurements of the range at which the first detection occurs 
and the relative positions of the ships at that time be re- 
corded. If we assume that the maximum relative closing rate 
of the two ships is fifty knots and that we must have the 
range measurement accurate to within one hundred vards, then 
the longest period of time that we can allow between meas- 
urements is .0l1 hours or roughly thirty six seconds. Hence, 


if the above situation were part of a time-stev game, the 


time-cycle might be set at, say, thirty seconds. The worst 
resolution in distance that could be expected under these 
circumstances would be about one hundred yards, with improve- 
ment at relative closing rates smaller than fifty knots. Now 
assume that the two ships start at positions twenty five 
miles apart closing at a rate of seven knots and that the 
average detection range on shiv A's radar is eleven miles. 
It will take about two hours for ship B to close to this 
average detection range. With a time-cycle of thirty sec- 
onds, the expected number of cycles before there is any ac- 
tivity on the radar is two hundred and forty plus or minus 
a few to account for the probabilistic effect in radar detec- 
tion range. During each cycle, ship A and shiv B will be 
advanced thirty seconds along their respective tracks. The 
probabilistic range law will be applied to determine if the 
detection has occurred, the necessary factors, if any, will 
be recorded and the clock will be advanced thirty seconds - 
- the game is now ready for the next cycle. In this vartic- 
ular instance the time-step procedure is not the best way 
to program the situation. 

There are, on the other hand, games where a discrete 
time-step is the best way to opnerate. Specifically, games 
in which time is not an important consideration, but rather, 
the order in which things occur. For example, in the board 
game of Chess, the players alternate at making moves and 


time is not a factor. This game could be programmed as a 
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time-step game where "time" is actually a misnomer and each 
cycle would consist of a decision and move by one of the 
players. 

Event-store game. Many games that involve force-units 
moving in a non-discrete manner can be broken up into a 
number of different events which occur with a varying amount 
of time between. For example, in the simple two-shin sce- 
nario just given there is just one event, that of making a 
detection. 

When a game can be broken up into events occurring at 
some determinable time, it may be best to use an event-store 
type game. The primary difference between an event-store 
game and a time-step game is that in the former a time cycle 
is not of fixed length. Rather, the occurrence of specific 
events in the game determines the length of time between 
cycles. At the completion of one cycle, it is determined 
at what time the next significant event is to occur in the 
game; the clock is then advanced directly to that time and 
the necessary activity associated with that event is wver- 
formed. Parameters of the game which are not associated 
with that event are not changed. 

In the example given, an event could be defined, anda 
routine provided, to record the distance from ship A to ship 
B and the relative positions of the ships. Then at the be- 
ginning of the situation a mathematical comnutation could 
be performed to determine the exact time at which the detec- 
tion would occur: an event could be stored for execution at 


the computed time. Since, in this case, that event would be 


1l 


the only one stored, the clock could immediately be advanced 
to the detection time and the routine would be executed, re- 
cording the necessary data. In this example, considerable 
computational effort would have been saved. 

The price that must be paid for this efficiency is 
usually complexity. Event-store games are considerably more 
complicated than time-step games. 

In both of these game types, one consideration is get- 
ting the games into and out of the computing machinery as 
soon as possible. As soon as all the actions or events due 
at a certain time are accomplished, the "game-clock" is ad- 
vanced either a fixed amount as in the time-step game or to 
the next event-time as in the case of the event-store game. 
The computations are performed, etc. Several replications 
of a game that may represent hours of real time may thus be 
compressed into minutes or even seconds of actual machine 
running time. In order to program a game of this type it is 
necessary to load the decisions that are to be made in all 
Situations into the program ahead of time. This is either 
done in the form of mathematical functions or tables. Then, 
when a decision point is reached it can be immediately re- 
solved. There is usually no "human" intervention in the 
game once it has begun. 

Interaction Games 

It may be the case that one of the factors to be meas- 
ured by the game is the effect of human decision making in 
the face of the available information and it may not be a 
Simple matter to characterize all of the possible conditions 
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ahead of time so that the resulting decisions can be tabu- 
lated. A good example of this sort of game is the game of 
Chess. There are so many combinations of moves and counter- 
moves in this game that it would be infeasible, if not im- 
possible, to store in advance the decision to be made for 
every situation. It may be more feasible to wait until cer- 
tain situations develop and then let a "human" decision be 
made. Another situation where it would be useful to have 
“man-machine" interaction is the case where the game is be- 
ing used as an aid to the teaching of decision-making. 

Consider the scenario of a Naval ship such as a de- 
stroyer searching for a submarine. It is desired that cer- 
tain newly proposed tactics for the surface ship be evalua- 
ted. The use of "self-contained" wargaming techniques in- 
volve programming the basic scenario with the application 
of the new tactics as a variable. Then the game is run sev- 
eral times with slight variations in the tactics; possibly 
with several replications on each, in order to collect 
statistical data on how effective the new tactics could be 
expected to be in the particular environment. Once the pa- 
rameters of the game have been set, it is not possible to 
make any changes. This type of wargaming is excellent for 
the evaluation of new tactics; however, when used as a train- 
ing device it loses much of its appeal since the players 
must make their decisions in a block before the run and then 
observe the results after the fact. There is no dynamic 
interaction, and hence, sometimes very little feel for what 
went on in all of the intermediate stages. 
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CHAP TR. fi 


REAL TIME GAMING SYSTEM 


The gaming system proposed here is aimed at filling the 
gap between strict self-contained games run purely for the 
evaluation of strategies and tactics and the hybrid training 
devices built specifically for the purpose of training veople 
in decision-making. The class of games which this system is 
designed to handle are those games in which most of the deci- 
Sions are made dynamically by the players in real-time. In 
this sort of situation, the computing machinery functions 
primarily as an umpire and bookkeeper, making sure that the 
decisions made by the individuals are legal in the framework 
of the game, and that all of the proper data and statistics 
are collected as the play of the game proceeds. 

The aim of the system is to provide a real-time gaming 
capability for a general purpose digital computer with a 
minimum of effort on the part of the programmer. Specif- 
ically, the system described here is proposed for implemen- 
tation on the International Business Machines System/360 
Model 67 installed at the Naval Postgraduate School. The de- 
tails of machine configuration are listed in Appendix H. 

In a real-time system a great deal of effort must be de- 
voted to general bookkeeping functions such as: event man- 
agement, input/output, maintaining force-unit status informa- 
tion, and collecting data. Many of these functions are the 


same from one game to the next with the only significant 
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difference being the flow of logic associated with the var- 
ious decisions in different game scenarios. The major fea- 
tures of the system are discussed in the following sections. 
Batch processing compatability 

One important attribute of a real-time system which is 
to be run on computing machinery normally devoted to other 
tasks, is that it run with a minimum of interference to 
those tasks. The proposed system is designed to operate in 
a multi-programming environment capable of vorocessing sev- 
eral users' programs at the same time. In this manner, the 
Real Time Gaming System can operate concurrently with the 
normal batch processing stream. The amount of central proc- 
essor time that is required by the system will usually be 
proportionately quite low compared with the total time that 
the game will be running on the system. Hence, it is to be 
expected that the degradation to normal batch service will 
be quite low. 
TmputZoukput management 

The primary device for input/output for this system is 
the standard tele-processing remote terminal provided by the 
computing machinery configuration. Each of the plavers, as 
well as the umpire, is stationed at one of these terminals 
and it is from this unit that he receives information and 
makes decisions as the play of the game proceeds. 

Under control of the generated Control Program, infor- 


mation can be freely passed back and forth among players and 
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between players and the system. This information includes 
message traffic, questions and replies, and control informa- 
tion to maneuver one's forces. 
Control Program Command Language 

In order to provide the functions required by the game, 
the control program must be coded by the user. In it the 
user provides all of the programming required to handle the 
specific circumstances which arise during the play of the 
game. The coding for the Control Program can be a mixture 
of some or all of the following: 

1. RTGS Control Program Command Language 

2. OS/360 Assembler Language? 

Oe ree even rv 

The command language provides most of the facilities 
that are required in a gaming environment. It will be dis- 
cussed in much detail later. The capability to use Fortran 
IV source programming has been provided so that mathematical 
calculations may be performed easily and the Assembler Lan- 
guage capability has been provided to handle logical informa- 


tlONn, String Manipulation, sit rcernaqyere ves 


li BM Corporation, IBM System/360 Operating System 
Assembler Language, Form C28-6514 (Poughkeensie: IBM Cor- 
poration, 1964) 


eTrerican Standards Association, FORTRAN, Communica- 
tions of the ACM, Vol. VII, No. 10 (Baltimore: Association 
for Computing Machinery, 1964) 
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Status-of-Forces Management 

As the play of the game proceeds, various force=units 
are introduced to and deleted from the theater of operations. 
They may also have various of their attributes such as veloc- 
ity or position undergoing constant revision. 

The Status-of-Forces Monitor is provided to automat- 
ically keep track of force-units and keep the information 
Gumment and correct.  —The user has the capability of adding, 
changing, reading out, or deleting any force information 
dynamically during the play of the game. 

Byvemt Management 

The proposed gaming system is basically an event-store 
type game with procedural modifications in order to accom- 
modate the real-time feature. All event management is done 
automatically by the system. The control vrogram can gen- 
erate events dynamically and turn them over to the system 
which, in turn, ensures that their corresponding event rou- 
tines are executed when they come due. The event routine 
is provided by the user. It is the actual sequence of 
operations that is to take place when an event occurs. 

Time Management 

Due to the real-time nature of the game, quite a bit 
of consideration must be given to keeping track of time. 
The basic time unit of the game is one second. Game-time 
is measured in true time since the beginning of the game; 
hence, the game-time at the end of one hour of play will be 


3600. The maximum game-time that the system can accommodate 


7 


is 65535 seconds, which is eighteen hours, twelve minutes 
and fifteen seconds. If this game-time is ever reached the 
game will terminate. 

It is possible to add a base-time to the game-time to 
make it correspond to any desired time-of-the-dav in order 
to add realism. Most readouts are displayed in hours, min- 
utes, and seconds. Several timing features are available 
to the generated Control Program and the timing services 
are all provided automatically by the system. 

Statrstics Gather igmociusrees 

As the play of the game proceeds, it is possible to 
gather any desired statistics in a running log or to tab- 
ulate key parameters in tables and/or counters. This data 


is available at the end of the game for offline processing. 
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CHAPTERad Lt 


SYSTEM OVERVIEW 


The Real Time Gaming System consists of three major 
subsystems. The Monitor System, the generated Control Pro- 
gram, and the Support Program Package. 

The Monitor System 

The monitor system is a fixed segment of the system 
which changes very little from one game to the next. It 
controls all input/outout functions, message handling, tim- 
ing functions, and multi-programming linkages. The game is 
always under positive control of the monitor system and it 
is through the monitor system that all linkages are per- 
formed. At the time of system generation (to be discussed 
later) the monitor will be built to accommodate the system 
Size that is desired -- this is mostly a function of how 
many players the system is to manage. At the heart of the 
monitor system is the Conversational Terminal Access Method 
(cTAM) ? Support package which performs the complicated in- 
put/foutput functions of the remote tele-processing termi- 
nals. The Input/Output Control Routine (IOCR) maintains an 
Input/Output Queue Control Block (IOQCB) for each of the re- 
mote terminals that may be on the line. This block contains 
the number of messages that are in the queue to be sent to 
each terminal, the number of outstanding renlies, anda 


pointer to the first Input/Output Control Block (I0CB). "man 


Scolumbia University, Conversational Terminal Access 
Method (CTAM), Columbia University Computer Center report 
CUCC-R-13 (New York: Columbia University, 1967) 


no 


IOCB is dynamically created each time a message must be sent 
towa cerminal. Let contains such information as: the length 
of the message, the actual text of the message, whether a 
reply is required and if so what to do with it, the time the 
message was sent, and other control information. The IOCB 
is placed in a chain as it is created with each IOCB point- 
ing to the next. The storage requirement necessary for an 
IOCB varies with the length of the text of the message; how- 
ever, it is dynamically allocated when required and released 
when no longer needed. A more detailed description of mes- 
sage handling is given in Chapter X. 

The monitor system performs all time functions. All 
timing information comes from the digital timer provided by 
the computer operating system. The monitor system sets, and 
processes all timer interrupts required to service the real- 
time requirements of the game. When control is relinquished 
to the other jobs in the batch processing stream, the timer 
is set to provide an interrupt causing a return to the gam- 
ing system when the next function (such as an event) comes 
due. 

The Status-of Forces Monitor segment of the system pver- 
forms the necessary functions to keep the status-of-force 
information for the individual force-units up to date. It 
performs the updating functions when a reference is made to 
a specific force-unit. Status information is stored in Force 
Status Control Blocks (FSCB) which are dynamicallv created 
when new force-units are added to the system. These blocks 


are chained as they are created with the Status-of Forces 
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Monitor maintaining the pointers necessary to retrieve the 
information. When a force-unit is deleted from the system, 
the block is removed from the chain and the storage is re- 
leased. A more detailed exnlanation of the Status-of-Forces 
Monitor is given in Chapter V. 

The Event Queue management section of the monitor sys- 
tem performs the functions required to nlace the events in 
a queue and set the appropriate flags when events are due 
to be executed. An Event Queue Control Block (EQCB) contains 
information on queue size and a pointer to the first Event 
Control Block (ECB) as well as the "event-due" flag. The 
ECB contains the actual information required to execute the 
event routine at the correct time. It is created dynamically 
in much the same manner as the FSCB and the IOCB. A detailed 
explanation of event queue management is given in Chapter VI. 
the Control Program 

The flexible part of the Real Time Gaming System, and 
the part that makes it available to a wide variety of users, 
is the Control Program. 

The Control Program consists of a sequence of commands 
which are provided by the user to handle all of the situa- 
tions that can arise in the play of the game. The commands 
are primarily taken from the RTGS Control Program Command 
Language supplemented by 0S/360 Assembler Language and For- 


tran iv" source coding, if desired. The command language 


4 TBM Corporation, IBM SYSTEM/360 FORTRAN IV Language, 
Form C28-6515 (Poughkeepsie: International Business 
Machines Corporation, 1966) 
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resembles any other higher level computer language in form 
but in substance the commands provided are snecifically tai- 
lored to gaming requirements. In this manner it is possible 
to perform complicated gaming functions by issuing single 
commands. The structure of the command language is the sub- 
ject of Chapter IV. 

Coding must be supplied at the entry point for the game. 
It is usually used to initialize certain variables and to 
perform other bookkeeping functions. A section of coding 
must then be provided to handle each event. When an event 
1s to be executed, control will be transferred to this sec- 
tion of coding. In addition, miscellaneous sections of 
coding can be provided for execution at any time. Subrou- 
tines written in any language and compiled into object form 
can be edited into the system and called by the Control Pro- 
gram when needed. Fortran IV and Assembler Language source 
coding may be inserted in the control program wherever de- 
Sired. A special command has been provided in the command 
language to separate coding in different source languages. 
Support Program Package 

A support program package has been provided for such 
routine functions as fixed-point toe floating-point conver. 
Sion, computation of square root, etc. These modules will 
be edited into the overall system at generation time as re- 
quired. 

Figure 2 represents the overall flow of activity of the 
system within the computer operating system environment 


Ze 


during the play of the game. Note that the system monitor 
is the only point of linkage between the Real Time Gaming 


System and the computer's overating system. 
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CHAP TE Relax, 


RTGS CONTROL PROGRAM COMMAND LANGUAGE 


The Real Time Gaming System is essentiallv a macro- 
compiler making use of the Assembler Macro Language” to as 
great a degree as possible. The command language consists 
of a series of macros which expand into Assembler Language 
coding during the system generation nhase. 

Definitions 

Some definitions which will be required for an under- 
standing of the command language are given here: 

Symbolic reference. A symbolic reference is a word 
having up to eight alphameric characters beginning with a 
letter or the special character #. They are used for two 
purposes: 

1. Branch point or entry point names: A name used to 
identify the location of a block of coding so that some 
other section of the program may branch to it. Symbolic 
references of this type may not start with the snecial 
Character +. 

2. Variable names: A name used to identify the storage 
location of a variable. Care must be taken not to confuse 
variable names with the actual variables. If the variable 


is fixed-point it will be referenced by a name starting 


> TBM Corporation, IBM SYSTEM/360 Operating System 
Assembler Language, Form C28-6514 (Poughkeepsie: IBM Cor- 
peration, 1964), pp. 59-99. 
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with a letter. if it is floating-point the name must start 
with the special character # followed by at least one letter. 
Symbolic references, either branch points or variable 
names, must have a total of from one to eight characters 
and may not contain any spaces. Those variable names which 
are going to be used in Fortran IV source statements must 


contain no more thaii@eix charae@tere Giwerder to confernece 


Fortran IV conventions. The following are valid symbolic 
references: 

BRP1 #VARIABL 

BRANCHL #V1 

VARIABLE Vil 


Note: In the above examples Vl and #Vl are different var- 
lables. 

Command. A command is some specific instruction, or 
set ofinstructionsy, # the Control Program which will Gees 
some pre-defined sequence of operations to occur. It will 
appear in the Control Program in one of two forms: 

1. The long form of the command will appear in the@tems 
mat; <COMMAND WORD>. It contains more than one word in some 
cases and the corner brackets <> must be coded. 

2. The short fom of the command will appeabeas ,onemes 
four letters coded with no spaces and without the corner 
Disoekects, €.g., CH. 

Operand. Each command, except a very few, must have 
some modifying information. This modifying information is 
supplied along with a command in the operand list which may 
have one or more elements. The operands in the opnerand list 
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are separated by commas and the general rule is that if an 
operand is to be left out, the comma must still be sunvlied 
to show its absence. In the case where overands are omitted 
from the end of the list, and no confusion can arise, the 
trailing commas are not required. Operands may be of anv 

of the following forms: 

1. Fixed~-point symbolic: The overand points to the 
storage location where the actual parameter resides. A 
fixed-point symbolic operand must begin with a letter and 
consists of uv to eight alphameric characters with no spaces. 

2. Floating-point symbolic: The operand points to the 
storage location where the actual parameter resides. A 
floating-point symbolic operand must begin with the special 
character # followed by at least one letter and consists of 
up to eight alphameric characters with no spaces. 

3. Fixed-point constants: The operand is the actual 
parameter and it is represented by putting the actual number 
in the list. It is differentiated from the symbolic overand 
by not starting with a letter. 

4. Floating-point constant: The operand is the actual 
parameter and it is represented by putting the actual number 
in the list preceded by the special character #. 

5. Literal constant: A literal constant is a strimg oF 
alphameric characters which are to be used in a message or 
for some similar use. It appears as the desired string en- 


closed in apostrophe quotes ('). If the avostronhe is 


Za 


required within the text of the message, it may be coded as 

a double apostrophe('') to differentiate it from the delimit- 
ing apostrophes. 

Command Language Format 


The commands will be given in the following format: 


OE 









COMMAND | OPERANDS 
[acon aa operandl|,{7t, overand3, <ici 
WHERE P50 
operandl = -*° etc. 


SS NE II LY Rapier IO At BIO ap Rep EA wT ter EE a Ah SL OT AOR ag SR el Da PRe AM  E AP  ae 


The following notational conventions will be used: 

Small letters. Small letters in the command descrip- 
tions represent words, names, etc. that must be replaced by 
some meaningful coding by the user. 

Caper eters. “Capi Leber tame on OC COCc Came 
shown. The same applies to the following seven special 


characters: 


Square brackets. [] indicate that the contents aremeps 
tional and need only be coded if the default is not to be 
taken. 

Braces. {} indicate a list from which only one thing is 
to be selected. 


Elipsis... dndieates an opensended plaice. 
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For example, in the format shown above, [name] means that the 
name field is optional and that the user will suvply an apnro- 
priate name if desired. <COMMAND> is the long form of the 
command and would appear exactly as shown. The short form is 
C and it also would appear exactly as shown. Operandl is re- 
quired and some coding must be supplied by the user. The 
rest of the operands are optional; however, if the second is 
coded it must be coded as l or 2. The actual length of the 
operand list is open-ended. The section labeled WHERE will 
give amplifying information concerning the limits of oper- 
ands, etc. 

There are several attributes and special storage loca- 
tions which are common to a great many of the individual 
commands. They are identified by the special character $ 
which must precede each. Some are specific to certain com- 
mands and will be discussed in the sections giving detailed 
descriptions of the commands; however, those which are com- 
mon to all commands are described here: 

1. Twenty five temporary storage locations which can 
be used as work areas are provided; they may be used at 
any point in the coding. They are given the symbolic 
names: $Tl, $T2,°°*,$T25. The advantage of using these is 
that the user need not define the storage himself. 

2. Common areas are provided for the purpose of passing 
information from one section of the Control Program to an- 
other. One hundred locations are provided and they are 


coded: S$Cl, $C2,°+*:,$C100. 


Zo 


3. In those commands involving the boolean switches 
that are available with event and status-of-forces blocks; 
the eight individual switches can be accessed by the sym- 
bole nancoemechGl mohoe,°***,hS8 Lor the event switches 
and SFS1, SFS2,°°*:°, SFS8 for the force-unit switches. An 
additional sixteen general switches are provided for access 
from any point in the Control Program at any time. They 
are accessed by the symbolic names: $GS1l1, $GS2,°**, $GS16. 

The individual commands are given in the Appendices 


with a detailed description of how each one works. 
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CHAPTER V 


STATUS=OR]~EORGES 


The operating forces in the game environment are divided 
into two major categories: stationarv forces and movable 
forces. 

Bima HOM =hOrces 

Stationary forces are those force-units which are not 
capable of moving, in time, through the theater of overa- 
tions either with respect to a geographical reference or 
with respect to other operating forces. As the game pro- 
ceeds stationary forces are capable of taking on or chang- 
ing various attributes. Examples of this type of force are: 

Ll. A supply facility with an inventory of replacement 
parts or materials which must be delivered to, or picked up 
by friendly forces. In this case the attributes could be 
the type and quantity of materials available or the delay 
of materials once ordered. 

2. A manpower pool from which men or labor can be drawn 
when required. 

3. Base facilities which might include the following: 

a. Repair facilities such as a shipyard or labor 
pool of mechanics. 
b. Replenishing or refueling facilities. 
c. Airports, landing fields, combat air strips, etc. 
Movable Forces 
Movable forces are those forces which are canvable of 


moving throughout the theater of operations, either without 


Sl 


limit or in some limited fashion. Among the imvortant attri- 
butes that such forces can have are: position with respect 
to some reference point, velocity in any or all coordinate 
directions, and any modifying information about the force 
itself. Some examples of this type of force are: 

l. Aircraft: Located in the theater of operations by 
its present position in a three-dimensional coordinate sys- 
tem with component velocities in the three directions. Addi- 
tional modifying information would be such factors as the 
number of passengers aboard, payload, weapons aboard, fuel 
remaining, etc. 

2. Ship: Located similarly to the aircraft, however, 
in only two-dimensions. 

3. Personnel: Either a single individual or a large 
group represented as a single unit. 

The manner in which movable forces may transit through 
the theater of operations will vary from one type of game 
to the next or even within a single game. In general; how- 
ever, the movement can be characterized in two board cat- 
egories, discrete and continuous. 

Discrete. Either the motion or the position of a force- 
unit may be discrete in nature. Discrete motion implies that 
the movement is discontinuous and often instantaneous. Sim- 
ilarly, discrete position implies "“pigeon-hole" placement in 
some specific location within the grid. The scale for dis- 
crete motion is usually ordinal and distances and velocities 


may be meaningless quantities as in the case of chessmen on 
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a chessboard: 


It is also possible that a force under dis- 


crete motion may disappear from one position and reapnear 


someplace else either immediately, as in the case of chess, 


Or after some delay in time, as in the case of a submanime 


periscope. 


Continuous. Either the motion or the position of a 


force may be continuous. Continuous motion implies that any 


position or velocity within some spectrum may be assumed. 


The scale for measurement is usually linear with distances 


and velocities being meaningful. 


some examples of the positioning of movable forces are 


given in Table l. 
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MOTION 












CONTINUOUS 





Naval ships or 
alrcraét movie 
in the theater 
of operations. 


Arrival, service, 
and departure of 
customers ata 
stationarv ser- 
ViCe vmael lity. 
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In the proposed Real Time Gaming System the movement of 
forces through the theater of operations is controlled by the 
Status-of-Forces Monitor. 

The scheme used to keep the status-of-forces up to date 
minimizes the bookkeeping by only updating force-unit infor- 
mation when a reference is made to that unit. A reference 
occurs in any of the following circumstances: 

1. The addition of a new force-unit to the theater of 


operations. 


2. The changing of any or all attributes of an alreadv 
existing force-unit. 


3. Inguiry as to the present status of a force-unit. 


4. Deletion of a force-unit from the theater of onera- 
ELonse 
5. Comparison of two or more force-units. 


Since there is no way that the force-unit can have any 
influence on the play of the game unless there is a reference 
made to it, it iS unnecessary to update it either period- 
ically or continuously between references. This saves time 
by avoiding any more bookkeeping than is essential. 

The Status-of-Forces Monitor maintains a Force Status 
Control Block (FSCB) for every unit in the system. This 
block contains the essential bookkeeping information for the 
unit so that the status of the unit may be determined at any 
time. A maximum of two-hundred fifty six blocks may be 
maintained by the system at any one time and each block 


contains the following specific information: 
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1. Unit designation: The unit designation is a unique 
number in the range (0-255) which is arbitrarily assigned to 
each force-unit when it is first introduced into the theater 
of operations. 

2. Type force: Information is stored indicating whether 
the force is stationary or movable and in the latter case 
whether the movement and positioning is discrete or contin- 
uous. 

3. Update-time: The update-time is the game-time at 
which the last update was performed -- this time represents 
the last time at which the currently listed status informa- 
tion was exactly correct. 

4. Force information boolean switches: Eight switches 
are provided which can be either set or reset by the control 
program to indicate various binary information about the 
force-unit. 

>. Force velocity: In the case of continuous motion 
forces the velocities are tabulated in each of the three 
coordinate directions. For discrete motion the velocity 
does not apply. 

@ Force position: The posdtwen of the force-unit wath 
respect to the origin of the grid is tabulated. In the case 
of continuous positioning, these are floating-point numbers 
which describe the distance (vlus or minus) from the origin 
along each of the three coordinate directions. In the case 
of discrete positioning they are fixed-point integers which 


indicate the "slot" in each of the three dimensions. 
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7. Force attributes: Depending on the force type, un to 
nine attributes may be stored in the block at any time. The 
attributes represent variable information which the Control 
Program requires for processing the force-units. These 


attributes are set and changed only by the Control Program. 


When a reference is made to an FSCB, the current time 
is fetched from the master clock and converted to game-time. 
This time is then compared with the "uvdate-time" in the 
FSCB. The difference in the times represents the amount of 
time that has lapsed since the last update was performed. 

If applicable, this time is multiplied by the velocity com- 
ponents to determine the distances traveled since the last 
update. This distance is then added to the position thus 
giving the new position of the force-unit in the grid. The 
update time is then corrected and the reference is serviced. 
In the case of discrete motion units, it is not necessary 

to compute the new position as a function of time; the force- 
unit must be moved in discrete steps by the Control Program. 
The actual construction of the FSCB is given in Appendix A. 
Status-of-Forces Commands 

The status-of-forces commands are provided to initially 
insert, change, and delete force-units to or from the 
theater of operations. A detailed description of each of 
the commands is given in Appendix B; a brief summary is 


given here. 


36 





———————— wee = 


NEW FORCE. The "New Force" command is used to introduce 
a new force-unit into the theater of operations. When it is 
introduced by this command, the type, stationary or movable, 
1s determined and mav not be adjusted during the play of the 
game. Every force-unit is identified by an integer in the 
range (0-255) and if a new unit is introduced having the 
Same designation as one which already is defined, the orig- 
inal will be cancelled. 

DELETE FORCE. The "Delete Force" command is used to 
remove a force-unit from play. After this command has been 
issued, the designation number is free for use to identifv 
another force-unit. 

READ FORCE. The "Read Force" command is used to fetch 
the present status of a force-unit. As a result of issuing 
this command the force-unit's FSCB will be undated and the 
requested status information will be returned. 

CHANGE FORCE. The "Change Force" command is used to 
change any or all of the characteristics of a force-unit. 

By using this command it is possible to go into the FSCB and 
change whatever factors are required in order to adjust 
pest tion, velocity, etc., of a force=unit. 

DISTANCE BETWEEN. The "Distance Between" command can 
be used to compute the distance between two force units in 
any one or combination of several coordinate directions. 

SET SWITCH ON. The "Set Switch On" command will set 
any combination of boolean switches associated with a partic- 
ular force-unit to the ON position. This allows decision 


making information to be stored in the FSCB for a unit. 
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SET SWITCH OFF. The "Set Switch Off" command operates 
in the same manner as the "Set Switch On" command; however, 
it places the switches in the OFF position. 

CHANGE SWITCH. The "Change Switch" command operates in 
the same manner as the "Set Switch On" or the "Set Switch 
Off" commands; however, it changes the position of the 


designated switches to the opposite position. 
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CHAPTER VI 


EVENT QUEUE MANAGEMENT 


Throughout the play of the game, decisions are made 
which do not necessarily require action to be taken imme- 
diately. These decisions must be nlaced in a queue so that 
they can take effect at the proper time. 

An event is any action or sequence of actions which 
occur at some specified time. Events can take many forms 
ranging from the simple posting of a flag to a long sequence 
of commands. There are two major categories of events in 
the system: those which are defined in the generated Con- 
trol Program ("game" events) and those which are used by the 
Monitor System for control purposes ("System" events). 

Game Generated Events 

The Control Program may define any sequence of commands 
aS an event; this sequence will then be executed every time 
that particular event comes due. 

A game generated event is the means by which the Con- 
trol Program can execute some specific sequence of commands 
when and under whatever condition it desires. When it be- 
comes apparent that some action is due in the future, an 
event is placed in the event queue with snecific information 
that will allow it to be executed at the correct time. There 
must be a section of coding in the Control Program to corre- 
spond to the required functions. When the event works its 
way to the head of the event queue at the indicated time, the 


Control Program will transfer control to the associated event 
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routine. If two events are placed in the event queue with 
the same execution time, the event designation will determine 
which event occurs first, with the lower numbered event being 
given priority. If both time and event number are identical, 
the order in which they were placed in the queue will govern 
-- they will be executed in FIFO order. 

system Generated Events 

When the system meets a requirement to execute some 
action in the future, it will store a "system" event in the 
same queue with the "game" events. A "system" event for 
the same time always takes precedence over a "game" event. 
The mechanics of "System" events is basically the same as 
that for "game" events; hence, they will not be discussed 
separately. 

Event Generation and Execution 

When the flow of the Control Program encounters the re- 
quirement for the generation of an event, the sequence of 
activities is as follows: 

An Event Control Block (ECB) is constructed containing 
the information necessary to execute the event when it comes 
due. The ECB is transferred to the Event Queue Control Rou- 
tine. The routine scans the queue to find the appropriate 
position for the newly created ECB. The block is then in- 
serted in the queue at the proper place. Meanwhile, the 
regular flow within the Control Program has been interrupted 
by the necessity to store this event. As soon as the event 
has been placed in the queue, the Control Program resumes -- 


then at some later time (as Short ase a fheaction of a Seconda 
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and as long as eighteen hours later) the event itself will 
come due. When this happens the system will set a flaq indi- 
cating that an event is due. Then at the first opportunity 
to do so, the system will shift control to the event routine 
which is either a Control Program defined sequence of com- 
mands or a segment of system programming, depending on whether 
the event was a "game" event or a "system" event. 
Event Routine Construction 

An event routine must be uniquely defined for every 
event designation which is used by the generated Control 
Program. It consists of a sequence of commands of any length 
desired; the only requirement is that the event does not loop 
infinitely, but rather, eventually takes an exit. Everv time 
an event in the queue with this designation comes due, the 
section of coding will be executed. The modifying informa- 
tion which is contained in the Event Control Block is avail- 
able to the event routine throughout its execution. 
Event Queue Control Block 

The Event Queue Control Routine maintains the Event 
Queue Control Block (EQCB) in order to keep track of the chain- 
ing information necessary for scanning the queue and posting 
the event in the queue. The block contains the following 
specific information: 

1. Event-due flag: The “event-due" flag is set by the 

monitor system when the top event in the queue is ready to be 


executed. 


41 


2. Queue element count: A count is maintained showing 
the number of events that are presently stored in the queue. 

eee eoriter: A polnter un the block is uséd to stare 
the chaining operation when the queue must be scanned. 

The actual construction of the EQCB is given in Appen- 
Cis A. 

Event ControUeetock 

The Event Control Block (ECB) is generated dynamically 
when an event is to be placed in the queue. It is then trans- 
ferred to the Event Queue Control Routine to be placed in the 
queue. The block contains the following specific information: 

1. Event=type flag: This tlag is ™used to distingumem 
"game" events from "system" events. 

24. End-or-queue flag: ‘This flag seeps the Chari] 
operation and indicates that this block is the final one in 
the queue. 

3. Pointer: A pointer to the next block in the queue is 
maintained for chaining. 

4, Time event due: The actual game-time that this event 
is due for execution. 

5. Event designation: The identification of the event 
routine that is to be executed when this event comes due. 

6. Boolean switches: Eight switches are provided which 
can be either set or reset by the Control Program to indicate 
various binary information needed for the execution of an 


event. 





7. Event modifiers: One fullword and two halfword mod- 
ifiers are provided in order to pass information to the event 
routine at execution time. Modifiers number one and two are 
halfwords and number three is fullword. 

Flow of Event Activity 

Figure 3 illustrates the flow of activities during the 
generation and execution of events. The Control Program gen- 
erates an event designated as number one due for execution at 
time six. The event is stored in the queue and control is 
returned to the Control Program. At time six, the system 
sets a flag to indicate that an event is due. At this time 
the event has moved to the top of the queue. The Control 
Program is allowed to execute until the first opportunity 
comes along for it to allow the execution of an event rou- 
tine. When this happens, control is transferred to the event 
routine for events designated one. The routine is completely 
executed and control is returned to the Control Program. 
Example of the Use of Events 

Suppose that in the play of the game it becomes neces- 
sary for a ship to fire a surface-to-air guided missile at 
an enemy aircraft. It is determined that the fire control 
solution requires the missile to be fired at game-time 3361. 
The Control Program could store a "fire-missile" event in the 
queue for time 3361. The "fire-missile" event could then be 
programmed to compute the time of intercept, the probabil- 
ities involved, etc. The event could then itself generate 


more events such as: 
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FLOW OF ACTIVITY IN EVENT MANAGEMENT 
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1. "intercept" which could inflict damage on the air- 
craft under certain probabilistic constraints at a time 
computed by the generating event -- say 3375. 

2. "reload-launcher" which could bring another missile 
out of the magazine when the first has had time to clear 
the launcher -- say at time 3369. 

3. “radar-contact" which could generate a radar contact 
on the aircraft's detection equipment corresponding to its 
Gerectionwof the massile, etc. 

Any of these events could then generate more events. 
For example, the "radar-contact" event could cause evasive 
action which could be determined to be successful or not by 
some probability distribution. Assuming it was successful 
it could then cancel the "intercept" event and generate an 
"evasive action taken" event which, in turn, could start the 
whole process over again back on the ship. 

Event Management Commands 

The event management commands are provided to define 
event routines and to store and cancel events. A detailed 
description of each of the commands is given in Appendix C; 
a brief summary is given here. 

Define Event Routine. The "Define Event Routine” com- 
mene as usedeatethe head ofmeach bikeck of codinggaen the 
Control Program, that represents the sequence of commands to 
be executed as the event routine. Every event routine is 


identified by an integer in the range (0-255) and the 
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corresponding identification is placed with the events in the 
event queue. No two event routines may have the same event 
designation. 

End Event Routine. The "End Event Routine" command is 
used to mark the last command in the event routine. It also 
serves as the command that causes control to be returned to 
the Control Program when the event routine is finished ex- 
Source l Ge 

Event Exit. The “Event Exit" command is provided to 
give the means of returning from the event routine to the 
Control Program in the middle of the event routine. Any 
number of exits may be used within an event routine. 

Store Event. The "Store Event" command is used at any 
time in the Control Program that it is desired to designate 
an event for execution at some time in the future. The 
"Store Event" command may also be coded inside another event 
eC liteaaiae 

Execute Event. The "Execute Event" command is provided 
to allow the immediate execution of an event routine. No 
event is stored in the queue as a result of this command. 
When the event routine completes execution, control is re- 
turned to the next command in the Control Program sequence. 

Cancel Event. The "Cancel Event" command is provided 
to allow cancellation of an event which has been stored in 
the queue. Only the first event encountered with the spec- 


ifications for cancellation will actually be canceled. 
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Global Event Cancel. The "Global Event Cancel" command 
is provided as a means of canceling all of the events that 


are stored in a given category. 
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CHAPTER VII 


CONTROL PROGRAM LINKAGE 


In order to provide a high degree of programming flex- 
ibility, the capability exists in the Control Program to 
shift from one programming language to another. During the 
pre-processing stage in system generation, the coding from 
different languages can be removed and compiled as indevnend- 
ent subroutines. The linkages which are required to pass 
control back and forth between routines are standardized so 
that no interface problems exist. The convention used is 
that of OS/360 Subroutine Linkages”. 

Programming may be done in anv source language desired, 
so long as the standard conventions are followed. In cases 
other than Assembler Language and Fortran IV, the compnila- 
tion is done separately and the object modules are edited’ 
into the system at system generation time. When it is neces- 
Sary to use Fortran IV or Assembler Language, source state- 
ments are inserted in the Control Program where desired, 


using the appropriate commands to mark the boundaries. 


oT BM Corporation, IBM SYSTEM/360 Onerating Svstem 
Supervisor and Data Management Services, Form C28-6646 
(Poughkeepsie: IBM Corporation, 1967), pn. 9-13. 


TBM Corporation, IBM SYSTEM/360 Opveratinda Svstem 
Linkage Editor, Form C28-6538 (Poughkeepsie: IBM Corpora- 


tion, 1966). 
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Linkage Commands 

The linkage commands are provided to ensure the prover 
interface exists between coding of various tyves. A detailed 
description of each of the commands is given in Appendix D; 

a brief summary is given here. 

Assembly Language. The "Assembly Language" command is 
issued to indicate the coding that follows will be Assembler 
Language. The OS/ 360 Assembler Language is then inserted 
in the Control Program coding in standard format. Comvat- 
ibility with the names and labels which have been assigned 
must be maintained. All general-purpose and floating-point 
registers are available for use. 

End Assembly Language. The "End Assembly Language" 
command is inserted after the last Assembler Lanquage source 
statement to indicate that the coding will return to RTGS 
Command Language. 

Fortran. The "Fortran" command is issued to indicate 
that the coding that follows will be Fortran IV source 
Statements. It is necessary to list in the operand list 
those variables, from the Control Program, which are to be 
used in the Fortran IV coding. Any such variables that are 
not in the list, and have the same symbolic references as 
variables in the Control Program, will be considered inde- 
pendent for purposes of this block of Fortran IV coding only. 
The only difference between the Fortran IV source coding 
used here and conventional Fortran IV source coding is that 
floating-point numbers are represented symbolically by start- 
ing with the special character #; whereas, fixed-point 
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symbolic references may start with any letter in the range 
(A-Z). The Fortran IV "IMPLICIT" statement may not be used 
in the Fortran IV coding; however, exnvlicit type declaration 
statements may be used. Symbolic references in Fortran IV 
statements may contain only six characters in order to con- 
form to Fortran IV conventions. 

End Fortran. The "End Fortran" command serves the same 
function in Fortran IV source coding as the "End Assembly 
Language" command did. 

Subroutine. The "Subroutine" command is used to indi- 
cate that the coding which follows is a subroutine coded in 
RTGS Command Language. The subroutine is usually used when 
several event routines and/or other blocks of coding perform 
the same function. The subroutine should not contain anv 
entry points except at the beginning via the "Subroutine" 


command. The following commands should not apvear in a sub- 


routine: "Do Periodically", "Signal At Time", "Signal After 
Lapse", “End of Game", “Return to™Monitor’, or any “Braneme 
command where the branch is external to the subroutine. In 


short, the subroutine must be self-contained. 

Return. The "Return" command is used to allow exit 
from the subroutine at any point desired within the routine. 
It provides for multiple exits. 

End Subroutine. The "End Subroutine" command must be 
the last command in the coding for a subroutine and fulfills 
the functions of the "Return" command as well as indicating 


the end of the subroutine coding. 
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Execute Subroutine. The "Execute Subroutine" command, 
when executed by the Control Program, causes a branch to be 
taken to the subroutine named in the operand. A parameter 
list is also provided in the operand and it will be passed, 
using standard linkage conventions, to the subroutine. The 
subroutine must either have been defined by the "Subroutine" 
command or have been provided at system generation time in 
object form. Upon completion of the execution of the sub- 
routine, control will proceed to the next command in the 
Control Program sequence. 

Return Code Branch. The "Return Code Branch" command 
1s provided to allow standard register fifteen return code 
conventions to be used in subroutines. 

Return to Monitor. The "Return to Monitor" command is 
provided as the standard end to a logical block of coding, 
e.g., the coding which is influenced by the "Do Periodically" 
command or the "Signal at Time" command. When this command 
is encountered in the coding stream, control passes from the 
Control Program back to the system monitor. The next com- 
mand in the coding stream must have a name field in order 
to provide a means for that section of coding to be executed. 
The "Return to Monitor" command may be used in an event rou- 
tine; however, it is not used as the standard exit from an 
event routine -- the "End Event Routine" command and "Event 
Exit" command have been provided for this purnose. 

End of Game. The "End of Game" command causes the game 


to stop. As a result of this command, the log will be brought 
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up to date, a tabulation will be made of events remaining in 
the event queue for execution, the terminals will be disabled, 
and control will be transferred to the comnuter's onerating 
system to terminate the run. 

Random Variable. The "Random Variable” command will 
link to a random number generator, as designated in the 
operand, and place the value of the random variable ina 


specified location. 
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CHAPTER VIII 


TIME MANAGEMENT 


The proposed system is designed to run in a real-time 
mode on computing machinery which normally onverates in a 
batch-processing mode. The time-management segment of the 
monitor system performs the functions necessary to run the 
game in real-time. Several definitions are renuired for an 
understanding of how the system accomplishes the real-time 
management. 
Real-Time 

Real-time refers to the actual time-of-the-day by the 
Clock. It effectively never stons. The basis for deter- 
mination of real-time is the digital timer which the comput- 
ing machinery hardware provides. In the System/360, Model 
67, it is a register which is undated every twenty-six 
microseconds. In the mode of oneration used by the RTGS 
monitor system, real-time is available to the nearest hun- 
dredth of a second. Internally the time is used to this ac- 
curacy to resolve some problems such as which of two "almost 
Simultaneous" events is to occur first; however, for most 
purposes the time will be truncated to the nearest second. 
Game-Time 

Game-time is the amount of real-time which has lansed 
Since the beginning of the game while the game "master clock" 
is running. It is the basis upon which all timing in the 
game is controlled. Game-time is specified in seconds since 


the beginning of the game. It is always expressed as an 
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imeeger in the range (0,65535). This corresponds to a maxi- 
mum of eighteen hours, twelve minutes and fifteen seconds 
representing the longest time that any game can run. 
Clock-Time 

Clock-time 1S game-time with some base added to shift 
it in time to some desired time-of-the-day. Clock-time is 
expressed in terms of hours, minutes and seconds; it is used 
only to add realism to the game and is never used internally 
for any control purposes. Most displays to the players are 
represented in clock-time. 


Master-Clock 





The master-clock for the system will always carry game- 
time. It may be started and stopped at any time under the 
control of the Control Program. The value of the master 
clock is available to the Control Program at any time. 

Time Management Commands 

The commands provided for time management are the means 
by which the Control Program may perform various activities 
which are a function of time. A detailed description of 
each of the commands is given in Appendix E; a brief sum- 
mary 1S given here. 

Set Time. The "Set Time" command is provided so that 
the Control Program can, at any time, reset the time pres- 
ently in the master clock. The game-time that is desired is 
coded with the command. As a result of issuing this command 


the master clock will be stopped. 
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Start Time. When the "Start Time" command is issued, 
the master clock will be started with whatever game-time it 
now contains. 

Stop Time. The "Stop Time" command will cause the 
master clock to stop with its present value. The actual 
time in the clock will not be adjusted. Care must be exer- 
cised when using this command. If the command which will 
be used to restart the clock is time-dependent (such as a 
command in an event routine), it will never be executed 
Since all future events will be frozen until the master 
clock is restarted. 

Present Time. The "Present Time" command will fetch 
the present game-time from the master clock and return the 
value as an integer in the range (0,65535). 

Present Clock. The "Present Clock" command will fetch 
the present game-time and add the appropriate base to it in 
order to convert it to clock-time. This time will then be 
broken up into its hour, minute, and second components and 
placed in the location designated. 

Set Clock. The "Set Clock" command is used to estab- 
lish the base time for conversion between game-time and clock- 
time. Clock-time will automatically wrap-around at midnight. 

Slgmal At Time. The "Signal At Time | command swiil arene 
cate to the system monitor that control is to be started at 
the point in the Control Program indicated by the operand at 


a specific time also indicated by an operand. This command 


is a conditional branch which is a function of time. Any 


Do 


number of signals can be set un for branch to some specific 
location without mutual interference. 

Signal After Lapse. The "Signal After Lapse" command 
is basically the same as the "Signal At Time" command except 
the branch occurs after a specific time lapse rather than at 
a specific time. 

Delay Until. The "Delay Until" command will cause ex- 
ecution of the commands in the Control Program stream to 
cease until the designated time. Meanwhile, the Control Pro- 
gram will execute any unexecuted event routines, and do any 
other work which may be backlogged. When the indicated time 
comes due, the Control Program will continue execution again 
with the next command in the sequence. When using this com- 
mand care must be exercised to keep track of the values of 
variables. There is nothing to prevent the value of a var- 
i1able which has been set prior to the "Delay Until" command 
from being changed by some other section of coding while 
the delay is in effect. 

Delay For. The "Delay For" command is basically the 
same as the "Delay Until" command except that the delay is 
for some specific length of time rather than until some 
specific time. 

Do Periodically. It may become desirable to conti 
uously execute a section of coding in the control program in 
an iterative manner. The "Do Periodically" command will com- 
mence its operation at a time specified in one of the oper- 


ands. The coding that follows the "Do Periodically" command 
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will be executed repeatedly in accordance with a cycle time 
specified in one of the operands. The operation will continue 
until either a specified number of iterations have occurred 

or until a time limit is reached. If many of these commands 
are going on at once, the system will be burdened with quite 

a bit of bookkeeping work and it is possible that the qame 


will draw back in time and start running late. 
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CHAE E Rix 


CONTROL PROGRAM LOGIC AND ARITHMETIC 


During the execution of the Control Program, it mav be 
necessary to make decisions dynamically based on the value 
of variables, the setting of boolean switches, or some other 
factor. The sequence of commands in the Control Program can 
be modified based on decision-making information and in this 
manner the play of the game can be controlled. 
Branching 

Most decision-making is done by branching. The sequence 
of commands in the Control Program is interrupoted and directed 
to some other place in the coding. The new entry point is 
usually designated by a symbolic reference in the name field. 
This reference is then used in the operand of that command 
which causes the branch to occur. The basis for a branch is 
usually either the setting of a boolean switch or the arith- 
metical value of a constant. 
Boolean Switches 

Each event has a set of eight switches which it can pass 
to the event routine. In addition, each force-unit is pro- 
vided with eight switches. The Control Program itself has 
Sixteen. These switches can, independently, or in groups, 
be set "ON" or "OFF". Then at any time in the game they may 
be interrogated to cause a branch based on their setting. 
Arithmetic 

A limited amount of arithmetic can be performed in the 


Control Program using the RTGS Command Language. If comvolex 
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mathematical functions are to be evaluated, Fortran source 
coding should be inserted. 
Logic and Arithmetic Commands 

A detailed description of each of the commands is given 
in Appendix F; a brief summary is given here. 

Set Switch On. The "Set Switch On" command can be used 
to turn any of the boolean switches to the "ON" position. 
They may be turned "ON" in groups within the same set or 
im@ividually. 

Set Switch Off. The "Set Switch Off" command can be 
used to turn any of the boolean switches to the "OFF" posi- 
m7on. 

Change Switch. The "Change Switch" command can be used 
to change the current position of the boolean switches to 
their complement. 

No Operation. The "No Operation" command does nothing. 
It is provided as a place to attach a branch point name or 
to provide a place for coding that is to be added in the 
future. 

Branch. The "Branch" command causes control to be trans- 
ferred to some other section of the Control Program. It 
names, in the operand field, a symbolic reference to the sec- 
Giem of coding which is to be executed next. 

Branch On Value. The "Branch On Value" command will 
evaluate the present value of a variable and take a branch 
based on any of the three mutually exclusive conditions -- 


negative, zero, and positive. 
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Branch All On. The "Branch All On" command will look at 
the present setting of a collection of switches designated in 
the operand and branch if all of the switches are in the "ON" 
position. Similar commands are provided to branch on other 
combinations ;.specrElcally © “Branch Any On", "Branch All @fame 
and "Branch Any Off". 

Add. The "Add" command will add any number of variables 
listed in the operand and place the result in a specified 
Locarlon. 

Subtract. The "Subtract" command will subtract two var- 
iables and place the value in a specified location. 

Multiply. The "Multiply" command will multiply any 
number of variables listed in the operand and place the re- 
sult in a specified location. 

Divide. The "Divide" command will divide two variables 
and place the quotient and remainder in specified locations. 

Set Value. The "Set Value" command will set the value 


of any variable to the amount specified in the operand. 
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CHAPTER X 


MESSAGE MANAGEMENT 


All messages generated during the play of the game -- 
those from the system to the players and those between the 
individual players -- are handled in the same manner. An 
overview of the message handling blocks was given in Chap- 
ter III; the blocks will be described in more detail here. 
Rapute/Output Queue Control Block 

One IOQCB is established at system generation time for 
each of the players which will be using the system plus one 
extra for the umpire. It contains the following information: 

1. Message count. This is a count of the number of mes- 
sages which are waiting to be sent to a particular player. 
2 Reply count... "This1s @ count of the number ver meee 


sages which have been sent and are presently awaiting a re- 


Se Oueue-status flag. This is a flag indieatame char 
there are presently no input/output control blocks in the 
queue. 

4. Pointer. This is an address pointer to the top IOCB 
in the queue. 

Input/Output Control Block 

One IOCB is created dynamically every time a message 
must be sent to a player. If no reply is required, the stor- 
age allocated for the block is released whenever the message 
is sent. If, however, the message requires a reply, the 


block is maintained in the queue until the reply is received. 
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When a reply is required for a message, the message is as- 
Signed a serial number which appears with the message when 
sent; this serial number must then precede the reply. In 
this manner the reply can be matched to the correct message 
in those cases where more than one reply is outstanding. 

The construction of the IOCB is shown in Appendix A. A sum- 
mary of its contents is given here: 

lL. Reply flag. This flag is»set to indicate that the ieee 
sage associated with this block requires a reply. 

20 Reply serial mumbers The field is only coded when 
reply is required and it stores the serial number, in the 
range (0,9), associated with the message. 

3. Length of 1I0CB. “This field 1s” used for storage aqvaam- 
cation purposes. It contains the length of the IOCB. 

4. End-of-queue flag. This flag is set when this IOCEWme 
the last one in the queuve. This information is used for 
chaining purposes. 

5. Pointer. This field points te the next IOCB in the 
chain. 

6. Length key. This field 1s coded with the length, am 
characters, of the message. 

7. Time sent. This field indicates the game-time that 
the message was actually sent to the player. 

8. Offset time. This field indicates the time which the 
action associated with a reply is to be delayed. This delay 
is coded in the Control Program by the command which creates 


the IOCB. 
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9. Reply event. This field is coded with the designation 
of the event routine, which is to be executed when the reply 
is received. 

10. Boolean switch. This field contains the boolean switch 
settings to be passed to the event routine when the reply is 
received. 

Hl. Text. The remainder of the Dlock const iGueeomiicmac— 
tual text of the message. 

Message Handling Commands 

The message handling commands are provided to initially 
create IOCBs and to indicate the action to be taken when a 
reply is received. In addition, commands are vrovided to 
tabulate and count data as well as to make entries in the game 
log. A detailed description of each of the commands is given 
in Appendix G; a brief summary is given here. 

Message to Umpire. The "Message To Umpire" command will 
cause a message to be sent to the umpire. No reply will be 
anticipated. Any variable from the program can be inserted 
into the message. 

Message to Player. The "Message To Player” command will 
send a message to any single player, any group of players and/ 
or the umpire. No reply will be expected. A variable from 
the Control Program can be inserted into the text of the mes-— 
sage. 

Message to Log. The "Message To Log" command will tab- 
mikate the variable indicated in the table indieated. This ying— 
formation is available for offline processing after Eneeoilay 


of the game. 
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Message FOr Replys, The “Message For Reply) command will 
send a message to any single player, any group of players and/ 
or the umpire. A reply will be expected and the disposition 
of the reply information will be coded with this command. A 
variable from the Control Program can be inserted into the 
text of the message that 1s sent requesting the reply. 

Tabulate. The "Tabulate" command will tabulate the var- 
liable indicated in the table indicated. This information is 
available for offline processing after the play of the game. 

Count. Sire "Count command iasmused to incrementeeme 
indicated counter. This information is available after the 


play of the game for offline processing. 
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CHAPTER XI 


USING THE SYSTEM 


The Real Time Gaming System has been designed to make 
the steps between the decision to run a game and the actual 
running of the game as simple as possible. Many of the com- 
plex steps in programming a real-time system have been built 
into the monitor system and do not need to be considered when 
designing a game. The major steps in running a desired game 
on the system are: design of the game, programming, system 
generation, and running the game. Each will be discussed 
separately. 

Design of the Game 

When the decision is made to run a game under the Real 
Time Gaming System, it will be necessary to design the game 
within the framework of the system. If the game of interest 
already exists as an event-store game, it will probablv lend 
itself well for adaptation to the system. 

The@tlow#of™liogic,; decisions, informativen jeetc., must 
be formulated in terms of events. It is necessary to decide 
what are significant events in the game, what are the alter- 
natives to various courses of action, what information is 
available at different stages of the play of the game, etc. 
This information must be formulated into an overall plan for 
the game. One way of representing this information might be 


ime a logic flowchart. 
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Programming 


When the design of the game is firm, it iS necessary to 
code the Control Program. This is done primarily in the RTGS 


Control Program Command Language supplemented by the 0S/360 





Assembler Language and Fortran IV. Each of the event routines 
is programmed as a self-contained block of coding. Any sub- 
routines which may be required are programmed; then, any gen- 
eral coding needed for the game initialization is provided. 

There must be at least one block of coding provided 
which is neither a subroutine nor an event routine. The first 
such block which appears in the Control Program will be con- 
sidered the entry point for the start of the game and initial- 
I Zeige! @Ini- 
System Generation 

When all of the programming is finished, it will be run 
through the system generation phase. This consists of two 
stages: pre-processing and object system generation. 

pre-processing. During the pre-presess@ngestagey, jeie 
syntax of the source statements will be checked and diagnos- 
tics will be produced to indicate errors in the source state- 
ments. If there are any errors, they will be listed; if there 
are none, the source program will be edited into a new form 
acceptable to the RTGS system generation stage. All of the 
Fortran IV coding will be removed and compiled separately. 


Object-system generation. If the pre-processing stage 


is successful, the statements, in their new form, will be 
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compiled and assembled into the final version. The result is 
a set of object modules ready to link edit into a single mod- 
ule ready for execution. 
Running of the Game 

When the game is to be run, all of the players station 
themselves at various remote terminals. At some pre-deter- 
mined time, they dial-in using the installation's standard 
tele-processing procedures. The only requirement is that the 
umpire must be the first person to dial in. After the umpire 
checks into the system, the whole logging-on process will be 
self-coaching by the system and it is only necessary to follow 
instructions. 

The play of the game will proceed until the first time 


the "end-of-game" command is encountered. 


CONCLUDING REMARKS 


The Real Time Gaming System, as proposed here, has not 
been fully implemented as of the time of the submission of 
this thesis. Most of the details in program logic have been 
worked out and enough implementation has been done to deter- 
mine that the system is feasible and will run with a reason- 
able degree of efficiency. The author intends to continue re- 
search and implementation of this system; it is anticipated 
that a fully operative system will be available at the Naval 


Postgraduate School within a year. 
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APPENDIX A 
SYSTEM CONTROL BLOCKS 
Fach of the system control blocks shown here are repre- 
sented in bytes of core storage. The numbers down the left- 
hand edge of the blocks represent the displacement from the 
beginning of the block. 


Input/Output Queue Control Block 








Se Re ie ET CN TC GS ES TS RN ce A “Ee Selamat 


MESSAGE COUNT | REPLY COGENT 


O82 te Sy qratr ane 











+0 


14 SUEVE-STATUS 


FLAG ADDRESS OF FIRST IOCB IN CHAIN 


Enpuc/Output Control Block 


? 2 eek gees OM Ele 6 Oe PAT Aer ete = ESO WO ete ee ws - wey RO 8 re eee et 





OL ae 











“REPLY SERIAL 
: tocc 
+0} REPLY FLAG en NUMBER | LENGTH OF THIS IO 
ae oo: ee. ce ee) 
+4} BND-OF-QUEUE ADDRESS OF NEXT IOCB IN CHAIN 
FLAG 
+8| LENGTH KEY UNUSED TIME MESSAGE SENT 
BOOLEAN 
$12 OFFSET TIME REPLY EVENT} Gocco 
+16! ACTUAL TEXT OF THE MESSAGE ... 
+8n-4|  ... END OF TEXT FILLER TO MAKE BLOCK AN 
EVEN MULTIPLE OF EIGHT. 
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Force Status Control Block 


CE a een ho NUM ee 






























UNIT 
DES ICNATION ere hae ik BLOCK ; 
POR GH a nyep 1: BOOLEAN 
KEY SWITCH UPDATE TIME 
4.8 ‘ X-COMPONENT VELOCITY 
seal ATTRIBUTE NUMBER FOUR | 
412 i Y-COMPONENT VELOCITY | 
cial ATTRIBUTE NUMBER FIVE 
ne 7 Z-COMPONENT VELOCITY 
TT AT@RIBUTE NUMBER Six 
+20 al A-POSHETLON 
TTt ATTRIBUTE NUMBER SEVEN 
424 T Yq-rOo Lillo 
TTT ATTRIBUTE NUMBER EIGHT 
+28 | T Z-POst rion 
Ttt ATTRIBUTE NUMBER NINE 
+32 ATTRIBUTE NUMBER ONE ATTRIBUTE NUMBER TWO 
+36 ATTRIBUTE NUMBER THREE 
a For continuous movement and position force 
i: For discrete-motion, continuous-position force 
Ta For stationary forces 
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Event Queue Comerolweloeck 
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MODIFIER NUMBER 1 
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MODIFIER NUMBER 2 
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APPENDIX B 


oTATUS-OF-FORCES COMMANDS 


Many of the operands that appear in the status-of-forces 
commands are common to some or all of the commands, hence, 
they will be described in some detail first. 

Unit Designation 

The unit-designation operand is the unique integer in 
the range (0-255) which is used for reference to the force- 
unit by the generated Control Program as well as by the sys- 
tem. When coded, the fixed-point symbolic or the fixed-point 
constant form of the operand may be used. 

Force-Type Key 

The force-type key only appears in the "New Force" com- 
mand and once a force-type has been designated it may not be 
Changed. The key consists of either one letter which stands 
alone or three letters which must all be present and in the 
correct order; they are: 

Il. Type designation. If the force-unit 1s stationaigs 
an "S" is coded alone and no other codes are required; under 
this condition there are seven fullword attributes and two 
halfword attributes available. "Fullword" and "halfword" 
refer to the storage capacity of various storage locations. 
Table B-2 gives the range of values that can be stored in 
each size. If the force unit is movable an "M" is coded in 
the first position. For a movable force-unit the number of 
attributes available will vary. When the "M" is coded the 


following two codes are also required: 





2 


2. Force-motion key. If the motion of she gierce [aa 
discrete, i.e., if the velocity components are meaningless, 

a "D" is coded in the second position. If the motion is con- 
tinuous, a "C" is coded in the second position. 

3. »Forcespositioning key. If ‘the posieoning so aeciie 
forces is discrete, i.e., if the relative position is ordinal 
and distance between units is meaningless, a "D" is coded in 
the third position. If, on the other hand, the posltionmangd 
of the forces is continuous, i.e., distance along the coor- 
dinate directions is a meaningful quantity, a "C" is coded in 
the third position. 

The only combinations which may appear are listed here 
with the number of attributes available to be assigned to the 
potee-—unit. 


EORCE=—TVEE FULLWORD HALFWORD 








KEY ATTRIBUTES | ATTRIBUTES 
S 7 Z 
MDD 4 2 
MDC 4 2 
MCD it 2 
MEC 1 2 
Table B-l 


Boolean Switches 

The boolean switches are available in the same form to 
all force-unit types. The purpose of the switches is to store 
decision-making information of a binary nature about the 


force-unit. When a force is initially defined by the "New 
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Force" command all switches will be defaulted to the "OFF" 
position unless the "boolean switch" operand is coded. If 
provided, it is given as an eight bit binary number indica- 
ting a l in the position(s) where the switch is to be turned 
ON. For example, if it is desired to turn on the third and 
fifth switches, the operand is coded as 00101000. The coding 
of the operand in the commands which change the individual 
Switches is in alist form. The list is coded in parenthesis 
in the form (S1,S2,::*); where the individual operands can be 
either fixed-point symbolic references or fixed-point con- 
Stants. Each must be an integer in the range (1-8) renresent- 
ing one of the eight switches. 

The "time" operand, when coded, is used to indicate the 
game-time at which the force-unit will be referenced. It is 
specified in seconds since the beginning of the game, hence, 
it must be either a fixed-point symbolic reference or a 
fixed-point constant in the range (0-65535). Note: it is 
possible to make references in the past and future; however, 
the present velocities and attributes will be used to compute 
what the status was or will be at the reference time, hence 
it is possible to get a false status of the force-unit if 
changes have occurred or will occur between the present time 
and the reference time. Since references in the past repre- 
sent history, it is never possible to make a retroactive 
change; similarly, a change in the future cannot be made ahead 
of time. On all references that involve change, the time pa- 


rameter should be left out. If it is desired to ensure that 
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the change occurs at an exact time, the time can be specified 
and corrections for delay of the system from the real-time 
will be made to record the change at the specified time. It 
should generally be sufficient to allow the system to assign 
the present game-time. 
Coordinate Velocities 

On force-units which are movable, the X, Y and Z coor- 
dinate velocities are provided in their respective operands 
in order to describe the motion of the force-unit in the 
theater of operations. When initially defining new forces, 
the velocities are defaulted to zero unless they are spec- 
ified. The operands may be either fixed or floating-point 
and may be either symbolic or constant. When making changes, 
it is only necessary to provide the operands for the coordi- 
nate directions that are being changed. The velocity is 
given in distance units per second along the axis directions. 
Coordinate Positions 

For movable forces which are pnositioned discretely, the 
operands are either fixed-point symbolic references or fixed- 
point constants placing the unit on the playing grid in its 
relative ordinal position. For force-units which are posi- 
tioned continuously, the operands are either fixed or float- 
ing-point and either symbolic references or constants which 
describe the distance from the origin along the three coordi- 
nate directions. As in velocities, only those distances 


being set or changed need be coded. 
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Attributes 


The number of attributes which are available varies with 
the force-unit type. The number that are allowed under the 
various types is tabulated in Table B-l. The fullword attri- 
butes may be fixed or floating-point; the halfword attributes 


may only be fixed-point. The range of the various attributes 


is given in Table B-2. 
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WORD SIZE WORD TYPE RANGE 


Fullword Floating-point + 7 x LO 

Fullword Fixed-point JT aero 

Halfword Fixed-point ee ho 
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al,a2,a3] 
a. as MDD 
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MDC 
[name ] a ad U., Silt, tana: ,aQ] 
WHERE 
u = unit designation; integer in range (0-255); fixed- 


point symbolic or constant. 
b = boolean switch; binary number with eight bits. 


t = reference time; integer in range (0-65535), fixed- 
point symbolic or constant. 


vX = x-direction velocity component; fixed or floating- 
point fullword, symbolic or constant. (Samara, 
HOneVY and vz. 


px = position along x-axis; fixed-point symbolic or 
constant for discrete and fixed or floating-point 
symbolic or constant for continuous. Similarly 
Bop y and pZ. 


al = attribute #1; fixed or floating-point symbolic or 
constant for fullwords and fixed-point only for 
boltwords.. Similarly fOr sa2fa3, 00 see 
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Bunction 

The function of this command is to introduce a new force- 
unit into the theater of operations. If a force-unit with 
this designation already exists it will be deleted. Once the 
force-unit type has been designated by this command it may 


not be changed during the play of the game. 


ia 


Example 


1. In this example it is desired to define an aircraft 
initially at a distance of ten nautical miles from the grid 
Origin, on the x-axis, and at an altitude of six thousand 
feet. The initial velocity is inbound toward the grid origin 
at two hundred knots. This aircraft is to be given the force- 
unit designation twenty-six, attribute number one is to have 
a value of ten, and the boolean switch number two is to be 
set ON indicating "enemy" aircraft. 

The command to define this new force-unit would be: 
<NEW FORCE> 26,MCC,01000000,,#=277.7,4,20000,,2000,1 Oe 
The floating-point -277.7 represents the velocity in yards 
per second. The fixed-point 20000 represents the distance 
in yards. Note that only those factors which are non-zero 
need be included. In this case the present qame-time would 
be assigned to this position. 

2. Place a King (represented by boolean switch number 
one) on the fourth row and third column of a chess board. 
Set attribute number one to a value of one to indicate that 
this is the black King. Designate as force-unit number one. 

The command to define this new force-unit would be: 

NF L MDD? 10000 GOGH 3 3451. 
Note that in this case the short form of the command was 


used. 
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Command description 
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eee OND 
<DELETE FORCE> 
[name ] } DF f ul ,plyb2, > aan) 


_WHERE _ aaa ———— 





~ 


u = unit designation; integer in range (0-255); fixed- 
point symbolic or constant. 


pl = player to be notified; integer in range (0-11); 


fixed-point symbolic or constant. ~Simi larvae. 
[ee Sete pl) « 


Bunetion 
The function of this command is to delete the indicated 
force-unit from the theater of operations. The unit designa- 
tion indicated is now free for use by some other force-unit. 
The players listed in the "p" operands will be given a mes- 
Sage to indicate that the unit was deleted. The message 
will appear in the form: 
0246:35 FORCE-UNIT 6 DELETED 

Example 

l. It is desired to cancel force-unit six and notify 
the umpire as well as player number one that the cancellation 
has occurred. The following command will accomplish this: 

<DELETE FORCE> 6,0,1 

2. Assume that it is not desired that any players be no- 
tified of the cancellation and that a fixed-point value of 
Six is already stored in location "SIX"; then the command 
could be given as: 


<DELETE FORCE> SIA 
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WHERE 


unit designation; integer in range (0-255); fixed- 
point symbolic or constant. 


vl,v2,°°* = list of variable symbolic names which are 
to receive the status information currently 
stored for the force-unit. The position 
of the variables in the list is the same 
as that in the <NEW FORCE> command used to 
define the force-unit, starting with the 
boolean switch operand. 


EE ol pe ad 





Function 
The function of this command is to update the FSCB fee 

the designated unit and return the requested information. 
This is done by placing the information into the locations 
indicated by the symbolic references which appear in the 
operand list. Only those factors which are needed should be 
requested. 
Example 

1. Suppose we desire to know the distance of force-unit 
twenty-six, which was the aircraft defined in the example 
given under <NEW FORCE>, along the x-axis. We desire to 
place this value into the location symbolically represented 
by the name POSIT; the following command could be given: 


<READ FORCE> 26,,,POSIT 
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Command Descriupeon 






[name } 


mame aan pant 


ec 


px = 


NOTE: 





[name] 
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Gre 


WHERE 
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unit designation; integer in range (0-255); fixed- 
peint symbolic or constant. 


boolean switch; binary number with eight bits. 


reference time; integer in range (0-65535); fixed- 
point symbolic or constant. 


x-direction velocity component; fixed or floating- 
point fullword, symbolic or constant. Similarly 
toe Vyeana Vz. 


position along x-axis; fixed-point symbolic or 
constant for discrete and fixed or floating-point 
symbolic or constant for continuous. Similarly 
fOpspyY ame pz. 


attribute#l; fixed or floating-point symbolic or 
constant for fullword and fixed-point only for 
Raltwords. “Similarly for AZ7es,°*° ,ae 


The first form is used for MCD or MCC type force- 
units: the second form for MDD or MDC type force- 
units: and the last for S type force-units. 
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Function 


The function of this command is to change any, or all, 


of the characteristics of a force-unit. If the force-unit 


has not been defined the command will take no effect. 


those characteristics which are to be changed are listed. 
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Only 


____COMMAND a 
ae ae a 
ul ,Db,t,VvX,VY ,V2¢2%,,DyY je ae 
al,a2, a3] 
SS la pia 
ul 7b,€;)DxX PY ;,D27aL, *° >> scem 


| 
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The others are left out and the corresponding characteristics 
will remain unchanged. If the "time" operand is not coded, 
the change will occur at the present game-time. No change 
can be made in the past or the future since it may effect the 
play of the game in the intervening time. It is possible, 
however, to designate a time to ensure that the change is re- 
corded at the correct time. If a time is coded, it must not 
be too far off the present game-time and specifying it as 
such can cause unpredictable results. 
Example 

Assume that a force-unit designated as six is of the 
MDD type and it is desired to set attribute number two to a 
fixed-point value of seventeen. In addition, attribute num- 
ber three is to be set equal to the floating-point value 
currently at the location with the symbolic reference #Dl. 
The following command would be used: 

<CHANGE FORCE> 6,,,,,,L¢,#DL 

If, on the other hand, this same command were issued 
and force-unit six was stationary (type "S") then the re- 
sult would be that attribute number four would be set to a 
value of seventeen and attribute number five would be set 


equal to the floating-point value currently at location #Dl. 
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Command description 
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___COMMAND ____.., OPERANDS" — ~. 
<DISTANCE BETWEEN> 1b ae) ee 
| DB uly Sy pall 
a = ee 
Pr 
| ul = unit designation; integer in range (0-255); fixed- 
point symbolic or constant. Similarly for u2. 
d = distance; fixed or floating-point symbolic refer- 
ence. 
t = reference time; integer in range (0-65535); fixed- 
Peint Symbolic. 
(x,y,z) = component reference list; integers in the 


range (0,1); fixed-point symbolic or constant. 
Deraules te a0, Un 0). 
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Function 
The function of this command is to compute the true dis- 

tance between two units in the theater of operations and 
place the value in the variable named by the "d" operand. 
If the "t" operand is coded, the reference time will be pro- 
vided. The list (x,y,z) is coded with a l to indicate the 
coordinates in which the distances are to be measured and 0 
in the coordinates which are to be skipped. If the list is 
coded (1,1,1) slant range will be given; whereas if (1,1,0) 
is coded, horizontal range will be given. If the list is 
not coded, (1,1,1) will be assumed. 
Example 

1. Suppose we desire horizontal range from force-unit six 
to force-unit seven. We want the result to be truncated to 


the nearest integer, converted to fixed-point and stored in 
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the location with the symbolic reference "DIST". The follow- 
ing command will be used: 
<DISTANCE BETWEEN> 6,7,DIST,,(1,1,0) 

2. Suppose now that we desire the altitude of the air- 
craft with force-unit designation nine and that the nine has 
been stored in a location designated ACNO. Suppose also 
that we want the computed value to be placed in the location 
symbolically referenced as DISTAC and we want the time of 
the reference to be placed into location TME. Then we want 
to read the position of all of the boolean switches for this 
same aircraft into location WHICH. We are force-unit six 
and the altitude measurement is to be made relative to our 
altitude. The following sequence of commands could be used: 

BRP4 <DISTANCE BETWEEN> 6,ACNO,DISTAC,TME, (0,0,1) 


<READ FORCE> ACNO ,WHICH , TIME ° 
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APPENDIX C 


EVENT MANAGEMENT COMMANDS 


Many of the operands that appear in the event manage- 
ment commands are common to some or all of the commands; 
hence, wthey will. be describedein Se@me s@eear lets ce 
Event Designation 

The event-designation operand is an integer in the range 
(0-255) which is used to reference the event routine by the 
individual events. When coded, the fixed-point symbolic or 
the fixed-point constant form of the operand may be used. 
Boolean Switches 

The boolean switches are available in the same form to 
all event routines. The purpose of the switches is to store 
decision-making information of a binary nature. When an 
event is stored by the "Store Event" command all switches 
Will be defaulted to the "OFF" position unless the "boolean 
switch" operand is coded. If provided, it is given as an 
eight bit binary number indicating a 1 in the position(s) 
where the switch is to be turned "ON". For examvole, if it 
1s desired to turn "ON" the third and fifth switches, the 
operand is coded 00101000. The coding of the overand in the 
commands which change the individual switches is in a list 
form. The list is coded in parenthesis in the form 
(S1,S2,°**), where the individual operands can be either 
fixed-point symbolic references or fixed-point constants. 
Each must be an integer in the range (1-8) representing one 


of the eight switches. A full set of switches is associated 
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with each event stored in the queue; they may be referenced 
by the event routine during execution by the symbolic refer- 
ences: SES1,SES2,°*:*,SES8. 
Time 

The "time" operand is used to indicate the game-time 
at which the event is to occur. It is specified in seconds 
Since the beginning of the game, hence, it must be either a 
fixed-point symbolic reference or a fixed-point constant in 
the range (0-65535). When an event is stored with a time 
which has already passed, it will be put at the ton of the 
event queue and flagged for immediate execution at the first 
Opportunity. 
Modifiers 

Three modifiers are available to each event in order 
to pass information to the event routine at execution time. 
Modifiers number one and two are halfwords, hence, thev 
must be coded as fixed-point symbolic references or as 
fixed-point constants. Modifier number three, on the other 
hand, is a fullword and may be coded as fixed or floating- 
point and either symbolic or constant. The range of the 
modifiers is given in Table B-2 in Appendix B. Within the 
event routine the modifiers may be referred to symbolically 


by the references: S$Ml, SM2, and SM3. 
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COMMANDS 


Command description 


OPERAND _ 
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WHERE 
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event designation; integer in range (0-255); 
Fixed-point symbolic or constant 
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EUneH1 on 
This command functions as a header to identify the be- 
ginning of an event routine. The commands that follow this 
One in the Control Program constitute the sequence of com- 
mands that are to be executed when the designated event 
comes due. Note: This command may not contain a reference 
name; if one is supplied it will be ignored. 
Example 
Assume that we wish to define the sequence of events 
constituting event three. The following coding would be 
supplied: 
<DEFINE EVENT ROUTINE> 3 
first command... 


second command... 
etc. 
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Command description 





COMMAND OPERAND cen 
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{SEND EVENT a 


re: eee 


PuneeLon 
This command functions as the last command in an event 
routine. It marks the end of the coding for the event 
routine and must be present. The next command in the Con- 
trol Program must have a symbolic reference in the name 
field since control is never passed to the next command 
after this one. 
Example 
Continuing the example given under <DEFINE EVENT ROU- 
TINE>, the <END EVENT ROUTINE> command would be inserted 
at the end of the block of coding. The resulting coding 
would constitute a complete event routine. 
<DEFINE EVENT ROUTINE> 3 
FiYSt Command. =. 


second command... 


last command... 
<END BEVENT SROur ENE 
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Command description 
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<EVENT EXIT> 
1p. Gili 





Function 


The function of this command is to provide for mul- 
tiple exits from an event routine. When this command is 
encountered in the event routine coding, an exit is taken 
and control is returned to the Control Program as though 
the entire event routine were executed. It is not necessary 
to place this command in front of the <END EVENT ROUTINE> 
command. 

Example 

Assuming that it is desired to take and exit from the 
event routine that was defined in the two previous command 
examples, we might have done so with the following sequence: 

<DEFINE EVENT ROUTINE> 3 
£1 Poe eOnmlidna ss. 

second command... 

<EVENT EXIT> 


BRE. command... 


Last. command as. 
<END EVENT ROUTINE> 


Note: In this example, when the <EVENT EXIT> command was 
used, it was necessary to give a symbolic reference name to 


the next command in the sequence. 
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Command description 
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e = event designation; integer in range (0-255); 
fixed-point symbolic or constant. 


t = execution time; integer in range (0-65535); 
fixed [porte syvmMoelic Geaconseante 


b = boolean switch; binary number with eight bits. 


ml = modifier number one; halfword; fixed-point 
symbolic or consi#ant. Similarly fiewemn2s 


m3 = modifier number three; fullword; fixed or 
floating-point symbolic reference or constant. 





— Rene gma 


Hun G Galen 

The function of this command is to cause one event to 
be placed in the event queue for execution at the game-time 
indicated in the "t" operand. The event routine that corre- 
sponds with the event designation must have been defined by 
a <DEFINE EVENT ROUTINE> command. The <STORE EVENT> command 
may appear anywhere in the Control Program coding including 
event routines; it may also appear inside the event routine 
wheleh it 1S Calling. 
Example 

Suppose we want to cause the event routine designated 
as event six to be executed at time 1776 and modifier two 
is to have a fixed-point value of nineteen. We could code: 


<STORE EVENT> 6,1776,,,19 
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Command description 
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WHERE 


All operands are exactly as coded in the <STORE EVENT> 
command. The "t" operand is not present. 
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Punetion 
The purpose of this command is to cause the immediate 

execution of the designated event. When the event routine 
1s completed, control is returned to the next command in the 
Control Program. Note: The <EXECUTE EVENT> command may not 
be issued within the event routine which it is calling. 
Example 

1. Suppose that in the Control Program coding it is 
necessary to execute event routine number six with modifier 
number three set to a floating-point seventeen. The follow- 
ing coding could be used: 

EXE Gas 

2. Suppose now that among other things, event routine 
six must execute event routine seven, and that it must do 
so by passing modifier number three on to event routine 
seven. 

<DEFINE EVENT ROUTINE> 6 


command... 
<EXECUTE EVENT> 7,,,,$M3 
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Command description 









<CANCEL EVENT | 
CE 


WHERE 
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e,t, and b are as defined in <STORE EVENT> command. 


While all three operands are optional, at least one 
of them must be coded. 


Func eon 

This command will find the first event in the queue 
which exactly matches the operands that are coded; this 
event will be canceled. Only those operands which are sup- 
plied will be used in the test. If more than one event in 
the queue has the characteristics given, only the first 
will be canceled. If no event is found with the character- 
istics, no action will result. 
Example 

Suppose that we had previously stored an event for 
event routine three to be executed at time 3778; and we 
now desire to cancel it. The following command would be 
used: 


<CANCEL EVENT> 3,3778 
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<GLOBAL EVENT CANCEL> 
GEC 


wee Re Oe ee ee a em et 
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e,t, and b are as defined in <STORE EVENT> command. 


While all three operands are optional, at least one 
of them must be supplied. 
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Function 


This command will find all of the events in the queue 
which exactly match the operands that are coded; these will 
all be canceled. Only those operands which are supplied 
will be used in the test. If no events which match are 
found, no action will result. 

Example 

1. Suppose it is desired that any event number three 
which is currently in the queue be canceled. The following 
command will cause this to be done: 

<GLOBAL EVENT CANCEL> 3 

2. If it is desired that all events with the eighth 
boolean switch "ON" and all others "OFF" be canceled, the 
following command could be used: 


GEC , ,OU00000R 


Note that in this case the short form of the command was 


used. 
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APPENDIX D 


LINKAGE COMMANDS 


The linkage commands are provided in order to give a 
means of transferring control from one section of coding to 
another. In all cases, the standard conventions for sub- 
routines for the OS/ 360 will be used. When a parameter 
list is passed to a subroutine or is defined in the command | 
"Subroutine", it will appear in the list form which consists 
of a list of variable references enclosed in parenthesis. 
When Fortran IV coding is mixed with the RTGS Command Lan- 
guage, it is only necessary to list the symbolic references 


as operands in an open-ended operand list. 


COMMANDS 


Command description 


z ; = : eee — - pene ae Ae Se 
paras ce tafe eA SEE ES SCE OTOP 8 I ie rr - me PAL ADT DLA OL, 
a Ne ee eee Op an oT oom 4 arena 


COMMAND OPERAND 


= S — - a ee tere tn ee me Sa em te a RR tet 
ee te RR me em me 5 - 


<END OF GAME> 
END 
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PURGE LOM 


The "End of Game" command is issued when the game is to 
be stopped for the last time. This command will cause all of 
the data collection, etc., to be performed. Any events which 
are still due for execution will be tabulated. The running 
log of the game will be brought up to date. When all of the 
end-of-game functions have been completed, control will be 
transferred to the computer's operating system to terminate 


Ene run. 
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Command description 
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Punction 
The function of the "Assembly Language" command is to 
indicate that the coding which follows in the Control Pro- 
gram will be O/S 360 Assembler Language. All general pur- 
pose and floating-point registers are free for use in the 
coding which follows. The "End Assembly Language" command 
serves to indicate that the last Assembler Language source 
statement has been coded and that programming will be in 
RTGS Command Language again. 
Example 
A typical sequence which might be used to clear the 

first seven boolean switches to "OFF" and return them to 
their force-unit might be: 

<READ FORCE> 6,$T1 

<ASSEMBLY LANGUAGE> 

Ni Stl, xe 

<END ASSEMBLY LANGUAGE> 

<CHANGE FORCE> 6,$T1 
The "Read Force" command brings out the current value of 
force-unit six's boolean switches; this word is placed into 
symbolic location "S$Tl1", then the "And" operation is done to 


change the first seven bits to zero. The adjusted word is 


then inserted back into the FSCB. 
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<END FORTRAN> ge 
EETN 
parnle= first@"symbolic references fuxeduome tf loatiing. 


point symbolic reference. Similarly for 
paw > 


Function 

The function of the "Fortran" command is to indicate 
that the coding which follows in the Control Program will be 
Fortran IV. It is necessary to place in the operand list, 
in any order, those symbolic references which will be carried 
over from the RTGS Command Language coding to the Fortran 
source coding. Those symbolic references used in the Fortran 
IV source coding which are not in the operand list will be 
considered independent for this block of Fortran IV coding. 
The "End Fortran" command serves the same purpose as the 
"End Assembly Language" command. 


Example 


“READ. FORCE> “6, 2450) ols 
<FORTRAN> Po ee or iee 

A = STL, + £872 + 6.3 

ioc. = A/ oe 
<END FORTRAN> 
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Command description 


NAME COMMAND OPERAND (S) 


(Gigi aI I MRP ae Gr 2 TT ame eck ge ae Gn, Alte a a EAR, ates ating at Pee 








(<SUBROUTINE> 

SUB [ (parmlist) ] 

<END SUBROUTINE> none 

ESUB 
— 
RET none 
WHERE hn emma, Tl 
parmlist = list of symbolic references; fixed or 


floating-point; enclosed in parenthesis. 
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Function 

The function of the "Subroutine" command is to indicate 
that the RTGS Command Language source coding which follows 
will constitute a subroutine. The parameter list will be 


passed to the subroutine using standard conventions for link 


age. The "End Subroutine" command marks the last statement 
in the subroutine and must be coded to separate the block of 
coding from that which follows. The "Return" command allows 
multiple exits to be taken from the subroutine at any point. 
Any number of "Return" commands may appear within a subrou- 
tine. The subroutine must be self-contained and not have 
external linkages other than by the entry point and "return" 
commands. The "End Subroutine" command performs all of the 


memecions of the "Return". 
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Command description 
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NAME COMMAND | COPERAND(S) 
mene) -EAHPGCUrE SUBROUTINE> mil, (parm) ice 

CALL 

<hieL > 
eee RETURN CODE BRANCH Bay bono 
RES j 
WHERE | 

nl = subroutine name; symbolic name reference. 


parmlist = parameter list for subroutine, fixed or 
floating-point symbolic references or con- 
stants which match the subroutine parameter 
Sess 


brpl = branch point name; symbolic name reference to 
be taken when return code is zero. 


brp2 = branch point name; symbolic name reference to 


be taken when return code is four. 
Srila ly see wep ope 


Punctlon 


The function of the "Execute Subroutine" command is to 


cause a branch to the designated subroutine with the parameter 


list as specified. The Control Program will transfer control 
to the subroutine for execution and will pass the parameter 
list in standard format. When the subroutine has completed 
execution, control will be transferred to the next command in 
the Control Program. If standard register fifteen return 
code linkage conventions have been used, the "Return Code 
Branch" can be used to cause multiple branching to the desig- 


nated branch points. 
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Command description 
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WHERE 
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gen = generator designation; symbolic name reference. 
Vv = variable to receive random variable; floating- 
point symbolic reference. 
Bunction 


The function of this command is to draw the next random 
variable from the generator specified in the "gen" operand. 
The variable will be placed in the location specified by 
the "v" operand. At system generation time the probability 
distribution from which the random variable will be drawn 
is specified as "Uniform", "Poisson (Exponential)", or 
"Normal". Any number of generators can be specified in 
order to maintain independence. 

Example 

Suppose that random number generator three had been 
designated as "Normal" with mean four and standard deviation 
one. The next random variable from this distribution may be 
drawn by issuing the following command: 

<RANDOM VARIABLE> 3,#RV 
The value returned would be anywhere in the range (-~,+©) ; 


however, it would most likely be in the range (+1.0, +7.0). 
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Command description 
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_____OPERAND __ 
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<RETURN TO MONITOR> none 
RTM 
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Function 
The "Return to Monitor" command is provided as the 
Standard end to a logical block of coding. For example, the 
coding which is influenced by the "Do Periodically" command 
must eventually return control to some other segment of the 
Control Program or to the monitor system. When the command 
is encountered in the coding stream, control passes from the 
Control Program back to the system monitor. The next com- 
mand in the coding must have a name in the name field in 
order to provide a means for it to be executed. 
Example 
Suppose that it is desired to execute event routine 
number six every thirty seconds. The following block of 
coding could be used: 
ConmaniGias: 
<DO PERIODICALLY> ,30 
<EXECUTE EVENT> 6 


<RETURN TO MONITOR> 
BRP command... 
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APPENDIX E 


TIMING COMMANDS 


Most of the operands that appear in the timing commands 
are common to several of the commands; hence, they will be 
described in some detail first. 

Time 

The "time" operand, when coded, is used to indicate 
either game-time or clock-time. In the case of game-time it 
1s specified in seconds since the beginning of the game; 
hence, it must be either a fixed-point symbolic reference or 
a fixed-point constant in the range (0,65535). In the case 
of clock-time, it is game-time plus some base time corrected 
to hours, minutes, and seconds; hence, it is represented as 
a set of three fixed-point symbolic references or fixed- 
point constants or combination. 

Branch Points 

Branch points are coded in order to symbolically rep- 
resent the entry point for control at specified times. They 
are specified as symbolic name references. 

Time Increment 

The "Do Periodically" command requires a time increment 
to be coded. It is represented in seconds and must be spec- 
ified as a fixed-point symbolic reference or a fixed-point 


constant. 
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COMMANDS 


Command description 













| NAME | COMMAND |  OPERAND 
ae <SET TIME> tl 
TIME 
WHERE 
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tl = game-time setting; integer in range (0,65535); 
fixed-point symbolic or constant. 
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Bunec lO 
The function of the "Set Time" command is to set the 
master clock to the time indicated in the "tl" operand. As 
a result of this command the master clock will be stopped 
and reset with the time specified. The clock will then re- 
Main stopped until started with another command. 
Example 
1. The normal use of this command would be during the 
game initialization phase. The following command could be 
given to set the clock up for a run: 
<SET TIME> 0 
2. Suppose that it is necessary to go back and pick up 
the game at time one hour. The following command could be 
given: 
<SET TIME> 3600 
It should be noted, however, that this would not necessarily 


duplicate the activities of an earlier run. 


LOZ 


Command description 





NAME | COMMAND [| ———=~=“C*éPRANDSC—C“‘~™S 
<STAR LT > 
uieme | GO a ! none 
<STOP TIME> 
[name] sie Ri 
Function 


Tie function of the “Start Time” command 1-meo stare 
the master clock; the setting presently on the master clock 
will be retained. The "Stop Time" command will cause the 
master Clock to stop; the setting will not be altered as a 
result of this command. 

Example 

During game initialization, the following sequence of 

commands could be used to get started: 


<SEL LIME 0 
<START TIME> 


command... 
Warning 
Care must be exercised when using this command. If the 


clock has been stopped by a "stop time" command, it must be 
restarted again by some coding which is able to be reached 
by the Control Program during the present time frame, i.e., 
if the "Start Time" command is located in an event routine 
which is not due for execution, the command will never be 


reached since the events are frozen by the stopped time. 
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Command description 
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| NAME “COMMAND OPERAND 
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[name ] debe" ata El mec) 
WHERE | 
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tl = game-time; integer in range (0,65535); fixed- 
point symbolic or constant. 


h = clock-time hours component; integer in the 
range 7(0,23); fixed-point symbolic or constant. 


m = clock-time minutes component; integer in the 
range (0,59); fixed-point symbolic or constant. 


s = clock-time seconds component; integer in the 
range (0,59); fixed-point symbolic or constant 
Function 
The function of the "Set Clock" command is to establish 
the relationship between game-time and clock-time. The "tl" 
Operand is coded with a specific game-time and the "(h,m,s)" 
operand is coded with the corresponding clock-time. The sys- 
tem will use this information to set the base time which will 
be used in the calculation of clock-times. 
Example 
Suppose that when the game is started the clock-time is 
supposed to be 1330:00; the following sequence of commands 
could be used in the initialization phase: 
<SreeLME, > 0 
<SET CuOenem™ 0 Sis 730-700) 


<START TIME> 
colmana.. 
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Command description 
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NAME 







ota, = 





‘<PRESENT TIME> i 
PT 
<PRESENT CLOCK> 
Papi Su 


game-time; fixed-point symbolic reference. 


h = hour component of clock-time; fixed-point 
symbolic reference. 


m = minute component of clock-time; fixed-point 
symbolic reference. 


Ss = seconds component of clock-time; fixed-point 
symbolic reference. 


st npn 
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Function 

The function of the "Present Time" command is to return 
the present value of the game-time to the variable designated 
in the "t" operand. The "Present Clock" command will return 
the components of clock-time which are coded to the locations 
specified by the symbolic references. 
Example 

Suppose during the play of the game it is necessary to 
know the game-time and clock-time. The following sequence 
of commands could be issued: 


<PRESENT TIME> $T1 
<PRESENT CLOCK> $172,$1T3,$T4 


As a result of these commands the required values will be 


available in the first four temporary storage locations. 
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Command description 
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tl = lapse time; integer in range (0,65535); fixed- 
potnt Fovumbolic Grsconstant.. 


t2 = game-time; integer in range (0,65535); fixed- 
pomnt Symbolic or constant. 


brpl = symbolic reference to a branch point. 

Fune@von 

The function of the "Signal at Time" command is to indi- 
cate to the system monitor that control is to be started at 
the point in the Control Program referenced by the second 
operand, at the time indicated by the first operand. The 
“Signal After Lapse" command causes the same thing to occur 
with the exception that the first operand is a time lapse 
between present game-time and the game-time that the branch 
1 Se Om OCG Lis: 
Example 

Assume that there is a block of coding which has a sym- 
bolic branch point name "BRP" and that it is desired that 
this coding be executed at game-time 3675. The following com- 
mand could be given during initialization: 


<SIGNAL AT TIME> 56 / opie 
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_____ COMMAND _ ee OPERANT 
<DELAY UNTIL-= ‘ail 
DU 
<DELAY FOR> 
! DF t2 





WHERE 
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game-time; integer in range (0,65535); fixed- 
Dolmt Symbolic jer eonstanite 


ct 
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delay time; integer in range (0,65535); fixed- 
point symbolic or constant. 
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Function 

The function of the "Delay Until" command is to cause 
the execution of the commands in the Control Program sequence 
to cease until the time designated in the operand. In the 
case of the "Delay For" command, the same thing occurs; how- 
ever, the operand is interpreted as a delay rather than an 
actual time. Meanwhile, the Control Program will execute any 
unexecuted event routines or do any other work which is back- 
logged. When the time indicated comes due, the Control Pro- 
gram will continue executing the next command in the sequence. 
Warning 

When using this command, care should be exercised to 
keep track of the value of any variables in the Control Pro- 
gram. There is nothing to prevent the value of a variable 
which has been set prior to the delay from being changed by 


some other block of coding which is executing during the delay. 
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Command description 
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<DO PE D > : 
(name ] | see [Stwainic ni ,ct]) 
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st = start time; integer in range (0,65535); fixed- 
point symbolic or constant; defaults to the 
present game-time. 


a 


inc = time increment; integer in range (0,65535); 
fixea-point “symbolic or constant; defaults to 
60 seconds. 


ni = number of iterations; integer in range 
(0,65535); fixed-point symbolic or constant; 
| defaults to 1000. 


eh TT 


ct = completion time; integer in range (0,65535); 
fixed-point symbolic or constant; defaults to 
end of game (65535). 
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Pung 1en 

The function of the "Do Periodically" command is to set 
up the monitor system to automatically branch to the sequence 
of commands which follow this one repeatedly with a cycle 
determined by the "inc" operand. Beginning at the starting 
time indicated in the "st" operand, the sequence will be ex- 


ecuted every "inc" seconds until one of two conditions occurs: 
1. The number of iterations specified in the "ni" operand 
is met. 
2. The completion time specified in the "ct" operand is 
emieountered. 


No execution of the sequence of commands will occur if any of 


the following conditions is true: 
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1. The start time is later than the completiensemmee 

2. The completion time is later than current game-time. 

3. The number of iterations is equal to zero. 
The number of iterations and completion times were defaulted 
high in order to allow coding only that one of interest with- 
out worrying about the other one interfering. In any event 
both conditions are checked and whichever occurs first will 
govern. 

This command may be nested as deeply as desired. It is 
possible to have an outer loop executing every hour with a 
nested loop executing every ten minutes for the first thirty 
minutes of the hour. 

Warning 

Over-usage of this command can cause the system to be- 

come bookkeeping bound, expecially in the case where the 


increment time is very short. 


Example 


Consider the case discussed above with nesting. The 
following sequence of commands could be used: 
<DO PERIODICALLY> ,3600,5 
<DO PERIODICALLY> ,600,4 
command. . . 
command... 


command... 
<RETURN TO MONITOR> 
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ref = reference to statement; branch point symbolic 
reference. 


Puneet On 

The function of the "Cease" command is to stov the exe- 
cution of a previously defined "Do Periodically" command. 
This command, when executed, will cause all future executions 
of the statements coming under the "Do Periodically" command 
to be canceled. The operand references the name field of the 


"Do Periodically" command that 1s being canceled. 
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APPEND 


LOGIC AND ARITHMETIC COMMANDS 


Many of the operands that appear in the logic and arith- 
metic commands are common to some or all of the commands; 
hence, they will be described in some detail first. 

Switch Type Designation 

When reference is made to one or several boolean switches, 
it 1s necessary to indicate whether the switches are those 
associated with an event, a force-unit, or the general switches 
available at any point in the Control Program. The "“switch- 
type" operand is coded with the letter E to indicate an event 
switch; this reference may only be made within the event rou- 
tine of the event being tested. If the "Switch-type" is 
coded G, the reference is to the general switches; and, if a 
number in the range (0,255) is coded, the reference will be 
assumed to be a force-unit. 

Branch Points 

Branch point references are made when it is necessary 

to designate the entry point to be used for a branch. The 


branch point is coded as a symbolic name reference. 
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COMMANDS 


Command description 
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<SET SWITCH OFF 
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<CHANGE oe 
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G = general switch; coded as shown 


u = force-unit designation; integer in range (0,255); 
fixed-point symbolic or constant. 


swl = switch designation; integer in range (1,16); 


hised— pod issn 0] U.CuomsCOns ban te weO.1 Malai, 
for sw2,sw3,°*°*° 
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Function 

The function of the "Set Switch On" command is to turn 
the designated switches to the "ON" position. The operand 
which lists the switches is coded in the list form,i.e., en- 
closed in parenthesis is a list of those switches which are 
to be affected by the command. Notice that it is not possible 
to change the event switches once they have been stored in 
the event queue. 
Example 

The following command could be used to turn the third 
and fifth switch "ON" for force-unit seventeen: 


<SET SWEECH ON: 170275) 


oe 2Z 


Function 
The function of the "Set Switch Off" command 2S yneeeeoe 
ciple, the same as the "Set Switch On" command. It will not 
be discussed separately. 
Humeti on 
The function of the "Change Switch" command is to change 
the present setting of the designated switch or list of 
switches to their complementary position. 
Example 
1. Assuming that force-unit seventeen has switches num- 
ber three and five "ON", either of the two commands given 
here could be used to turn switch five "OFF". 
<CHANGE SWITCH> 17 on 
<SET SWITCH OFF> 17, (5) 
2. If it is desired to turn switch five "OFF" and at the 
same time turn switch seven "ON" the following command would 
be used. 


<CHANGE SWITCH> 17, (5,7) 
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Command description 
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WHERE 


Ca A RE YY ar OO Gy re Gn SI AEE Aen Ee ee oe 8 ey OTT ae eee OE mp pen tend ELE ITY we gt OE te ee Oo meem i RE 


brp = branch point; symbolic reference to name. 
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EAI ake) 

The function of the "No Operation" command is to act as 
a place to anchor a symbolic name reference for branching 
purposes. It may be necessary to have some other section of 
the Control Program branch to this section of coding; however, 
1t may not be possible to put a symbolic name on the desired 
command either because it already has another name or because 
it is not one of the commands which allows a name field. In 
this case the "No Operation" command can be placed in front 
of this command with the name. The "No Operation" command 
can also serve as the temporary replacement for a block of 
coding which is to be added later. 

The function of the "Branch" command is to cause an un- 
conditional branch to occur to some other point in the Con- 
trol Program. The entry point 1s coded as a symbolic name 


reference in the operand. 
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: u 

<BRANCH ANY ON> 
[name ] ANYN same as above : 

<BRANCH ALL OFF> 

am 

: (name ] ee same as above ! 
<BRANCH ANY OFF> | 
[name ] ANYF same as above | 
WHERE 
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E = event switch; coded as shown. 
G = general switch; coded as shown. 


u = force-unit designation; integer in range (0,255); 
fixed-point symbolic or constant. 


sl = switch designation; integer in range (1,16); 
fixed-point symbolic or constant. Similarly 
fer S2;s3,°°*° 
brp = branch point symbolic reference 
panetion 
The function of the "Branch All On" et al. commands is 
to consider the list of switches given in the second operand. 
If the condition called for exists a branch will occur to the 
branch point name symbolically represented in the third oner- 
and. When the first operand is coded "E" the command must 
appear within an event routine; the switch list then refers 
to the boolean switches in the event which caused the execu- 
tion of the event routine. If the first overand is coded 


"G", the command can appear anywhere and the set of boolean 


LJ 


switches which is provided for the Control Program to use 
throughout the game will be used to determine the conditions 
for the branch. If the first operand is coded with an integer 
in the range (0,255), it will be interpreted to indicate one 
of the force-units which are presently being maintained by 
the status-of-forces monitor. 

In any of the following conditions, the command will 
take no effect: 

Ll. If the first operand is coded with an integer, indica- 
ting a force-unit, and the force-unit is not presently being 
kept by the status-of-forces monitor. 

2. If the first operand is coded "E" and the command does 
not appear within an event routine. 

3. If a switch designated in the switch list is outside 
of the range that is associated with the first operand. 
Example 

Suppose we desire to branch to the section of coding 
named BRP3 if and only if the boolean switches number one 
through seven in force-unit number six are in the "ON" posi- 
tion. We could use the following command: 

<BRANCH ALL ON> 6,(1,2,3,4,5,6,7) ,BRP3 
It would also have been possible to use: 
“BRANCH ANY OFF>> 6,(1,2,3,475,)0,/) ,/BRE2 


<BRANCH> BRP 3 
BReE2 ‘cConmand 
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Command description 
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test value; fixed or floating-point symbolic 












reference. 
branch point for minus; symbolic reference 
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branch point for zero; symbolic reference 
to a branch point. 


branch point for plus; symbolic reference 
POM amoGonch Poult. 
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Bunction 

The function of the "Branch on Value" command is to 
consider the value of the variable named in the first oper- 
and and based on its arithmetic value make a branch. If 
the value of the variable is negative, the branch will be 
to the second operand; if zero, the branch will be to the 
third operand; and, if positive, the branch will be to the 
fourth operand. If any of the branch point operands are 
not coded and the corresponding condition exists, the next 


command in the sequence will be executed. 
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res = result; fixed or floating-point symbolic 
reference. 


al“=wadeacna;,; rixea Of IlOating=boOlnt symbole or 
constant. Similarly a2,a3,°*:° 
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Function 
The function of the "Add" command is to adda list of 
addends and place the result into a location designated by 
the first operand. The list of addends may be of any length 
and if the symbolic reference designating the location of 
the result also appears in the list, the old value will be 
used for the calculation. Full mixed-mode (fixed-point and 
floating-point) arithmetic is allowed. 
Example 
1. The following command will increment the value of 
COUNTS by"one. 
<ADD> COUNT,COUNT,1 
2. The following command will add the values of #VAL and 
TEST and place the result in fixed-point into the location 
symbolically represented as ANSWER 


<ADD> ANSWER, #VAL,TEST 
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Command description 
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<SUBTRACT> 
| [name ] | SUB res ,min,sub 
| | Wee a 
res = result; fixed or floating-point symbolic 


reference. 


min = minuend; fixed or floating-point symbolic 
reference or constant. 


sub = subtrahend; fixed or floating-point symbolic 
reference or constant. 
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Function 
The function of the "Subtract" command is to perform a 
subtraction and place the result in the location symbolically 
represented by the first operand. If the "result" symbolic 
location also appears as one of the factors, the old value 
will be used in the calculation. Full mixed-mode arithmetic 
is allowed. 
Example 
1. Suppose that it is desired to decrement the value of 
the variable located by the symbolic reference COUNT by one. 
The following command could be used. 
<SUBTRACT> COUNT,COUNT,1 
2. The following command would do the same but the result 
would be converted to floating-point. 
<SUBTRACT> #COUNT,COUNT,1 
NOTE: The old value of COUNT would remain unchanged since 


#COUNT and COUNT are different variables. 
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Command description 














(NAME COMMAND [|  ~—~—S OPERANDS) —s 
< I > 
[name ] ol la Boece mileem. | .mer. °°] 
WHERE 
res = result; fixed or floating-point symbolic 
reference. 


ml = multiplicand; fixed or floating-point symbolic 
reference or constant. 


m2 = maltiplier; fixed of floating points moolic 
reference or constant. Similarly for m3,m4,°°° 
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Bunceron 

Tive £UnNCtiOn Of the “Multiply” command is to perfomnea 
multiplication and place the result in the location symbol- 
ically represented by the first operand. Any number of fac- 
tors may be multiplied together and if the "result" reference 


appears as one of the factors, the old value will be used for 


the calculation. Full mixed-mode arithmetic is allowed. 
Example 
1. Suppose we want to cube the number in the location 


whose symbolic reference is Vl, convert the number to float- 
ing point, and place the result into a location with the 
name #CUBE. The following command could be used: 


<MULTIPLY> #CUBE,V1,V1,V1 
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Command description 
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DIV 
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WHERE 
quotient = fixed or floating-point symbolic reference 
fon quotient. 


quotient,remain,dl,d2 








remain = fixed or floating-point symbolic reference 
for the remainder. 


dl = dividend; fixed or floating-point symbolic 
reference or constant. 
a2 = divisor; fixed or floating-point symbolic 


reference or constant. 


a a et a ON ED TM eg Deer Ret gS Oa EE A fe A ED TS TY FS SA 





ee ee a iis CD gama 





Function 

The function of the "Divide" command is to perform a 
division and place the results in the locations specified by 
the symbolic references. Full mixed-mode arithmetic may be 
used; however, if the quotient is floating-point, there will 
be no remainder term. If a remainder is specified, it will 
be set to zero. If the symbolic reference for either the 
quotient or remainder appear as factors for the division, 
the old value will be used. 
Example 

Suppose we want to divide the quantity in location 
#AMOUNT in half; the following command could be used: 


<DIVIDE> #AMOUNT, #AMOUNT, 2 
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Command description 
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variable to be set; fixed or floating-point 
symbolic reference or constant. 


val value; fixed or floating-point symbolic 


reference or constant. 
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Funciron 
The function of ,.the "Set Value" command is to set the 
value of some variable to a specified amount. 
Example 
Suppose we want to initialize the value of the variable 
symbolically represented by the name AMOUNT to a fixed-point 
quantity of seventeen. The following command would be used: 
<SET VALUE> AMOUNT,17 
If the value seventeen had already been assigned to another 
variable, say COUNT, the following command could be used: 
<SET VALUE> AMOUNT,COUNT 
If a floating-point seventeen had already been assigned to 
the variable named #COUNT, the following command could be 
used to perform the floating-point to fixed-point conversion 
prior to the new assignment; 


<SET VALUE> AMOUNT, #COUNT 
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APPENDIX G 


MESSAGE HANDLING COMMANDS 


Formats 

In most cases when messages are sent, they will be in a 
standard format. The text of the message will be edited from 
three parts. The first part is only present if the message 
requires a reply; it consists of the reply serial number en- 
closed in corner brackets. Messages which require a reply 
are serialized starting with zero then incremented by one for 
each new message until nine is reached, then the next is ser- 
ialized with zero again. The purpose for the serial is to 
allow more than one message requiring a reply to be outstand- 
ing for any specific player. When the player replies, he 
must also precede his reply with the serial to identify it. 
The second part of the text is the actual message requested 
by the Control Program. The last part is the numeric content 
of a variable location which the Control Program can request 
if required. 

In addition to the above editing, all messages which are 
typed at the player's terminal are preceded with the clock- 
time that they are sent. This clock-time is the same as that 
which is stored in the IOCB for this message and it is avail- 
able to the Control Program when the reply is received. The 
following is a typical message and its reply: 

1316:12 <2> WHAT IS NEW SPEED AFTER 1330 
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Operands 

Many of the operands that appear in the message handling 
commands are common to some or all of the commands; hence, 
they will be described in some detail here. 

Message text. The "message text" operand is always 
coded as a literal constant, 1.e., it is coded with the ac- 
tual message that is to be sent enclosed in apostrophe 
quotes. If an apostrophe is required within the text of the 
message, it is coded as a double apostrophe. 

Message variable. The "message variable" operand is pvro- 
vided to allow some variable quantity to be edited into the 
text of the message. It is coded as a fixed or floating- 
point symbolic reference. 

Player-unit designations. The "player-unit" operand is 
coded to indicate which player is to receive a message. The 
umpire has the designation zero, all other players have a 
number in the range (1,11). When the message is to go to sev- 
eral players it may be coded in the list form. In this form 
the list of players is coded in parenthesis separated by com- 
Masummeng se ( Ou 204 | Se, 

Reply event. When a reply is required, it is handled by 
the Control Program as an event. An event routine is coded 
assuming that the numeric reply is in modifier three at the 
time it is executed. Modifier one contains the time that the 
message was sent and modifier two contains the time that the 


message reply was received. 
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Boolean switches. When the "boolean switches" operand is 
coded in messages requiring replies, the switch settings will 
be passed to the event routine when the reply is received. In 


this manner the event routine can identify different messages. 
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COMMANDS 


Command description 
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<MESSAGE TO LOG> 
MSGL 





| 


eae a es 





mes = message text; literal constant. 
vl = message variable; fixed or floating-point 
symbolic reference or constant. 
Pune Elon 


The function of the "Message to Log" command is to make 
one entry in the running game log. The message variable, if 
coded, will be inserted after the text of the message. 
Example 
Suppose we desire to construct and enter into the log 

the following message: "FIRST DETECTION MADE BY UNIT/7". 
Suppose, further, that the seven in the text of the message 
must come from a variable symbolically represented as VU2. 
The following command could be issued: 

<MESSAGE TO LOG> "FIRST DETECTION MADE BY UNIT’ ,VU2 
When the message is entered into the log, the time will be 
edited, with both game-time and clock-time, into the entry. 
The following represents the way the log entry will be made: 


1316:21 8593 FIRST DETECTION MASE BYOUNLT 7 
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Command description 
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COMMAND _______ OPERANDS 
<MESSAGE TO UMPIRE> SeuelRea | 
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WHERE 
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message text; literal constant. 


vl = message variable; fixed or floating-point 
symbolic reference or constant. 


ul = player identification; fixed=pointesymoolic 
reference or constant. Similarly for u2,°°° 
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Punetion 

The function of the "Message to Umpire" command is to 
send the text of the message, as designated in the first 
operand to the umpire. It will be assumed that no reply is 
required. The message variable, if coded, will be inserted 
after the text of the message. The function of the "Message 
to Player" command is essentially the same as the "Message 
to Umpire" command. The message will be sent to the players 
designated in the list. If it is desired that the umpire be 
included, zero should be coded in the player list. 
Example 

The following is an example of a command that will send 
a message to both the umpire and player three. 


<MESSAGE TO PLAYER> (0,3),'SPEED IS',#VEL 
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Command description 
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"NAME | ~COMMAND—s OPERANDS | 
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<MESSAGE FOR REPLY> vaglimn Suess! od , 
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ul = player identification; integer in range (0,11); 


fixed-point symbolic reference or constant. 
Similarly emer Orher UitS 1 rnelis ft 
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mes = message text; literal constant. 


(0,255); fixed-point symbolic reference or 
constant. 


a ee 


| 
| 
| 
e = event designation for reply; integer in range 


b = boolean switches; binary word with eight bits. 


vl = message variable; fixed or floating-point symbolic 
reference or constant. 
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Function 

The function of the "Message for Reply" command is to 
send the text of the message, as designated in the first opver- 
and, to the player. It is assumed that a reply is required; 
and, when the reply is sent by the designated player, the 
event routine designated in the "e" operand will be executed 
with modifier number three set to the reply that the player 
sends. In addition, modifier number one will contain the 
game-time that the message was sent to the player and mod- 
ifier number two will contain the game-time at which the 
player responded. The boolean switch settings will also be 


passed to the event routine for identification purposes. 


We 


Example 


Suppose we are coding the message used in the example at 
the beginning of this appendix; the time that is to be inserted 
into the message text is in the location symbolically repre- 
sented by TIME. Assume that event routine six is to be exe- 
cuted when the reply is received. The following command could 
be used: 

MSGR 3,'WHAT IS NEW SPEED AFTER' ,6,,TIME 
This command would cause the message to be typed at the ter- 
minal of player three in the following format: 

1316:12 <2> WHAT IS NEW SPEED AFTER 1330 
Assume now that the reply was received from player three at 
Clock-time 1317:27, and that the speed was six. When the 
reply was sent it would appear in the following form: 

<22 0 

As a result of this reply, the system would transfer control 
to event routine number six with modifier one set to the 
game-time associated with 1316:13; modifier two set to the 
game-time associated with 1317:27 and modifier three set to 


be 
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Command description 








| _NAME COMMAND [|  ~*OPERAND ss si 
<TABULATE> | 
[name ] | TAB Gabel (werea 
<COUNT > , 
[name ] CNT ent [,inc] 
eo rae ee. 
tab = table designation; integer in range (0,255); 





fixed-point symbolic reference or constant. 


vl = variable; fixed or floating-point symbolic 
reference or constant. 


freq = frequency; integer; fixed-point symbolic 
reference or constant; defaults to l. 





cnt = counter designation; integer in range (0,255); 
fixed-point symbolic reference or constant. 
inc = increment; integer; fixed-point symbolic 
reference or constant; defaults to l. 
Penrehvon 


The function of the "Tabulate" command is to tabulate 
the variable specified in the "vl" operand in the table des- 
ignated; the frequency tabulated will be that indicated in 
the "freq" operand. If this operand is not coded, a frequency 
of one will be assumed. The "Count" command will cause the 
counter designated in the "cnt" opnerand to be incremented by 


the amount specified. 
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APPENDIX H 


MACHINE CONFIGURATION 


This proposal for the Real Time Gaming System is made 
with the goal of implementation on the computing machinery 
available at the Naval Postgraduate School. The central 
processor is an International Business Machines System/360, 
Model 67-2 with a core storage capacity of 524,288 bytes. 
Tele-processing is accomplished through a 2702 Transmission 
Control Unit with a capacity of twelve lines. The remote 
terminals are 2741 Communication Terminals linked to the 
central processor by the 2702. Eight 2311 Disk Drive Units 
and a 2301 Drum are available for auxiliary storage. 

The operating system, under which the Real Time Gaming 
System is designed to run, is the MVT option of 0S/360. 

The input/output is controlled using the Conversational Ter- 
minal Access Method (CTAM) developed by the Columbia Univer- 
Sity Computing Center. 

It is anticipated that the system could be implemented 
on any IBM System/360 with the standard and floating-point 
instruction sets if a tele-processing capability were avail- 


able for that system. 
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APPENDIX I 


SAMPLE GAME 


The following is a sample of the Control Program for a 
Simple game. The details of the coding are not explained, 
but the game is straightforward and the programming should 
be clear. The game itself was not chosen for its elegance, 
but rather because it uses most of the features of the sys- 
elie 

The object of the game is to test the reaction time of 
the players in responding accurately to a request from the 
umpire. The umpire sends a number to the players. They must 
guess the largest integer in the square root of the number 
(the answer to 67 would be 8) and respond. The first player 
to respond is the only one that can score. He receives ten 
points for a correct answer and loses five points for an in- 
correct answer. When the umpire wants to stop the game he 
Simply sends a negative number. In no case will the player 
be allowed more than ten seconds to make his response. The 
coding provided is not necessarily the best way to program 
the game; however, it illustrates the details of the program- 


ming and shows what a typical Control Program might look like. 
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SAMPLE 


NAME 


BRP 1 


DP1l 


BRP2 


BRP 3 


BRP4 


PROGRAM 

COMMAND 
“Sel ov IME > 
<START CLOCK> 
<MESSAGE TO PLAYER> 
<NEW FORCE> 
<NEW FORCE> 
<SEr SWITCH OFF> 
<SET SWITCH OFF> 
<SoLeOWLECGH OFFS 
<MESSAGE FOR REPLY> 
<DO PERIODICALLY > 
<BRANCH ALL ON> 
<RETURN TO MONITOR> 
<CEASE> 
<SUBTRACT > 
<BRANCH ON VALUE> 


<MESSAGE TO PLAYER> 


-<BRANCH> 


<BRANCH ALL ON> 


<MESSAGE TO PLAYER> 


<COUNT> 


<BRANCH> 


<MESSAGE TO PLAYER> 


<COUNT> 


<BRANCH> 


iss 


OPERAND (S) 


(0, 1:2) e,.' READY TOsc DARE 
iS 

2,8 

LG) 

27) 

G, Gi 

(0) ,'SEND TEST NUMBER’ ,5 
ea! 


G,(1,2) ,BRP2 


DPl 

ST 7, odlaonee 

$T7,BRP5,,BRP3 

(0,1,2),'TIE ON TIME, NO SCORE 
THIS ROUND! 

BRP1 

1,(1),BRP4 

(0,1,2),'PLAYER 2 RECEIVES 10 
POINTS' 

C20 

BRP1 

(0,1,2),'PLAYER 2 LOSES 5 
POINTS ' 

Cc] ,-5 


BRP1 


Bie 


BRP6 


e 


<BRANCH ALL ON> 
<MESSAGE TO PLAYER> 
<COUNT> 

<BRANCH> 

<MESSAGE TO PLAYER> 
<COUNT> 

<BRANCH> 

<DEFINE EVENT ROUTINE> 
<MESSAGE TO PLAYER> 
<MESSAGE TO UMPIRE> 
<SET SWITCH ON> 

<END EVENT ROUTINE> 
<DEFINE EVENT ROUTINE> 
<MESSAGE TO PLAYER> 
<MESSAGE TO UMPIRE> 
<SET  SWLTCH sON- 

<END EVENT ROUTINE> 
<DEFINE EVENT ROUTINE> 
<FORTRAN> 
ST1=SM2-SM1 

J ll—Serka (Fol 10) 
PCr, FO. SM) 
SM3=-1 

CONTINUE 

<END FORTRAN> 
<CANCEL EVENT> 


<SET SWITCH ON> 


134 


GO le, 1 


2,(1),BRP6 
(0,1,2),'PLAYER 1 RECEIVES 10 
POINTS' 

eine 

BRP1 

(O42) SeLAVER 1 LOSES 5 
POINTS' 

C1,-5 

BRP1 

1 

1,'YOU RAN OVERTIME' 
'PLAYER 1 RAN OVERTIME' 


de) 


2 
2,'YOU RAN OVERTIME' 
'PLAYER 2 RAN OVERTIME' 


2s) 


3 


$M1,$SM2,$5M3,#5T10,5T1,ST im 


BRP / 


BRP 8 


BRP9 


BRP10 


d. 


<BRANCH ON VALUE> 


<SET SWITCHVON> 


<BRANCH> 


<MESSAGE TO PLAYER> 


<MESSAGE TO UMPIRE> 


tv EXELT> 


<MESSAGE TO PLAYER> 


<MESSAGE TO UMPIRE> 


<END EVENT ROUTINE> 


<DEFINE EVENT ROUTINE> 


<FORTRAN> 
S$T2=SM2-SM1 


ST12=SORT (#ST10) 


Tries Pik? . EO.SM3) «GO TO l 


SM3=-1 

CONTINUE 

<END FORTRAN> 
<CANCEL EVENT> 

<SET SWITCH ON> 
<BRANCH ON VALUE> 
<SET SWITCH ON> 
<BRANCH> 

<MESSAGE TO PLAYER> 
<MESSAGE TO UMPIRE> 
“even BEXLT> 


<MESSAGE TO PLAYER> 


Ls 


$M3,,BRP7,BRP7 

Ll) 

BRP 8 

1,' YOUR ANSWER WAS CORRECT; 
YOUR TIME WAS',ST1 


'PLAYER 1 RESPONDED WITH 
CORRECT ANSWER IN TIME' ,$T1 


1,' YOUR ANSWER WAS INCORRECT; 
CORRECT ANSWER WAS' ,S$T1l1 
‘PLAYER 1 RESPONDED INCORRECTLY ' 


4 


SM1 ,SM2y M3, et LO Say ST 12 


2,$T8 

G,(2) 

SM3,,BRP9,BRP9 

Zee) 

BRP10 

2,'YOUR ANSWER WAS CORRECT; 
YOUR TIME WAS' ,$T2 


‘PLAYER 2 RESPONDED WITH 
CORRECT ANSWER IN TIME' ,$T2 


2,'YOUR ANSWER WAS INCORRECT; 
CORRECT ANSWER WAS' ,T12 


BRP11l 


<MESSAGE TO UMPIRE> 
<END EVENT ROUTINE> 
<DEFINE EVENT ROUTINE> 
<BRANCH ON VALUE> 
<SET VALUE> 
<MESSAGE TO PLAYER> 
<PRESENT TIME> 
<ADD> 

<SP@RE EVENT> 
<STORE EVENT> 
SSyveNl x el 

<END OF GAME> 


<END EVENT ROUTINE> 


Poo 


‘PLAYER 2 RESPONDED INCORRECTLY ' 


5 

SM3,BRP11 

#$T10,$M3 

(1,2) ,'WHAT IS LARGEST INTEGER 
IN THE SQUARE ROOT OF',S$M3 

ST9 

SE Oo cleo © 

aos 


2,$T8 
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